ERRATA - The cost of failure is only nearly zero if you iterate quickly. If you wait 6 months to demo it to your stakeholders, well... you get what you deserve. - I somehow got NFTs and NFC mixed up. What a shame, it's a halfway decent joke otherwise. - I realise I didn't mention what I recommend. I'd start with: + A 5-minute standup in the morning + Around a kanban board + With a WIP limit of team size/2 + Demo as often as you can - NOT ALL DOCUMENTATION IS BAD, sorry I wasn't clear. I love code documentation, api docs, etc - what I don't like is process documentation, overhead documentation, all the stuff that literally doesn't matter if you don't do it.
@@NoBoilerplate I've heard so much good stuff about pairing, but as an introvert I find it exhausting and the opposite of fun. What I love is diving into a challenge, grokking it, solving it, then sharing it for review/discussion. Pairing (for me) is good for knowledge transfer and overcoming real blockers, but otherwise I want to play music and code by myself.
My limited experience is mostly solo projects that are quite detached from other current work. In that case I would still say do the standup just in case there is the possibility for knowledge sharing. But also a weekly +-30min meeting with whoever is in charge of the project your work is attached to. Keeps everyone up to date and it is nice to have some fixed time to look at what the ideas/issues are. Never skim on documentation though. Even if it is the basic stuff, someone who is new to the environment you use will thank you for it.
@@LoveLearnShareGrow extremely relatable - try using a 10-minute pairing as a kick-off on a task. Get going with help from a friend, then do the rest of the work solo
At my last job, I let my manager know that I felt that we were having too many meetings, and he told me that he valued my insight, and scheduled a meeting to discuss the matter.
We should all reject meeting invites that don't describe the objectives of the meeting. The "How the world will look different after this meeting" approach is good.
I worked at a place this summer and by week 2 I got my manager to completely ditch sprints and stories. We had a small team of 3 and just had a list of tasks and just took the highest priority issues. When someone got stuck we did pair programing. Probably the smoothest and fastest working project I have ever worked on. Really hate all the ceremonies involved in scrum
This works because you're 3 people. Grow to 8 and it will most likely fall apart unless everybody has the same knowledge/seniority and way of doing things (which is rare).
@@strangnet Ever heard of the "pizza team" ? Also ... the more tickets in a single column of your Kanban, the harder it will be to make sure you don't forget anything
I prefer "briefings" over "meetings", if that makes sense. For example: we were considering moving from RIBs to an architecture optimised for SwiftUI, but we weren't sure which one. The initial meeting to discuss this matter was pretty much an hour wasted. However, a senior engineer ended up implementing every single viable option within our existing skeleton -- the briefing to explain his findings took us to a conclusion within twenty minutes.
I was at a company one time for about 2 1/2 years. We had a scrum master whose job was basically just to waste everyone's time organizing scrum meetings and install and manage processes. We had a 6 month cycle that went like this: -New scrum processes/set of meetings gets announced -Everyone tries to follow it for about 2 weeks and then anxiety due to lack of productivity began to build -Every starts quietly ignoring the processes as much as possible to get work done -Productivity eventually grinds to a halt, disasters begin to mount -By month 4, we're in full-on firefighting mode. Everyone completely and totally throws all rules out the window, stops giving a shit about anything process-related, and just starts working and getting shit done. -By month 6, the smoke clears. -New scrum processes/set of meetings gets announced.
I recently re-wrote a piece of internal software. It took me about 4 days of prototyping, then actually doing it. Then another week of testing. After two weeks, yi told my boss about the re-write, and that it was done and now working better-than-ever. Had I asked about the project beforehand, the planning phase alone would have taken a month
Working in video game industry, I can say that for small teams, you might be right. But for large-scale team with limited budget, deadlines, changing scopes, and large number of people from various disciplines, "over planning" is kind of necessary.
Totally understood. My video isn't to say that I am smarter than a million software companies doing things with heavyweight processes - but that it's important to question the one-size-fits all approach. I'm advocating starting from the agile manifesto and working up. In many companies you'll reverse-engineer sprints, and that's fine if that's what works at your company - but I bet it'll be more custom.
@@NoBoilerplate I actually tried that, it did not end well. I was fed up with the amount of time we spent in meetings yelling at each other about how things sucked instead of working on solving the problems. Suggesting that picked the people that could (and should) solve the problem and move forward resulted in more yelling. BTW: The term "planning" needs some explanation. There is the planning where people estimate time and drag things out on a Gannt chart, and then there is the planning when software engineer(s) look at a problem and determine how to break it into manageable parts (often creates an architecture). The first is useless, the second is critical. Some people treat the "no planning" approach as if people should just start typing out code on a keyboard; this rarely works. I find that there is a big difference between "coders" and "software engineers"; coders write code, software engineers solve problems using and writing software.
@@NoBoilerplate Scrum Master here with a genuine question, without any estimation, how can a company assess volume for client expectation setting on large scale projects? Like most companies, ours wants to continue to grow, so we are always lining up new projects, but without estimation one could overfill the pipeline and ruin relationships due to a failure to deliver within a reasonable time frame. Generally my guilds have placed the focus on being close with our estimates (we use story points, so ideally within 1 deviation up or down) and focus on learning about what questions we can ask or what discovery we could have done if the difference is significantly larger. In our planning we don't spend much time on the estimate itself and instead focus on making sure whoever is tackling the work has as much info as they need to feel comfortable with the task. I understand the pragmatic desire to mitigate superfluous meetings and try to safeguard that for my guilds, but those I hear being proponents of an estimate-less, and status meeting-less environment I don't feel are considering some of the real business necessities outside of the Dev dept. Also, how would a company set a budget for a project without a relative understanding of the effort, personnel, and time required to complete it? Please don't read any of this as snark, it's me genuinely trying to improve my game to better support my guilds and understand divergent view points.
@@benmerk4086 Hi Ben, you sound like one of the good ones, I've had the pleasure of meeting many in my career. My problem with estimating individual stories is that my feeling is that the bounds for error are well over 100% due to the extra stuff that happens during a sprint to get work done. Undiscovered problems and hold-ups, or the other way, with work that is surprisingly easy. Estimation at the story level is what I have a problem with, because it seems to me to be just as good as top-down estimation. And top-down estimation doesn't take up any of my expensive team's time. To be clear: story planning and kicking off I'm down with, seems useful. But estimating time or effort? That's a much more dubious value proposition for me, after 15 years of developing. 1/TFB/NFC might me 90% of the way there ;-)
We shared this video in the company and I talked to the dev team I work closest with if we should change anything, drop any meetings etc. They unanimously said that all the meetings are needed and that they really like the way we work. We are running 3-week sprints and do a production release after each sprint and the team likes that we can cherish the progress we made together. But in turn we keep all other meetings to a minimum: We only meet when there is something to discuss and make sure only the people attend that are involved in the agenda. Team likes it, customer likes it therefore I like it 🙂
Corporate agile = several waterfalls happening simultaneously while not being able to find documentation divided in 50 pieces stored in 100 different places
Your point on estimation is a breath of fresh air. I always hated being asked to estimate how long something would take as I really never had a clue. Then I started following the advice of "however long you think it's going to take, double it" and all of a sudden people are asking me why everything is going to take so long. I don't know!!
@@NoBoilerplate I'm honestly super duper happy you are exploring out of your comfort zone. The video you just shared is by far the most interesting and valuable technical video I have watched ever.
I love this! This is definitely going on my bookmarks. My last company used SAFe, and I completely related to the “spending more time in meetings than actually writing code” part. I HATE story estimation, and think it’s too arbitrary of a metric. I feel like a lot of the stories I estimated could have been done by the time I finished estimating them! The approach you suggested is what I’ve been thinking this whole time. Every team is different, and you can’t force a complete methodology and business practice on everyone. It needs to be *agile* and adaptable. However, taking a massive project and not breaking it down or tracking the pieces is overwhelming, so agile is certainly valuable, it’s just about analyzing it objectively, taking what works, and leaving what doesnt
My previous company did this and it drove me completely insane. You saw some improvement you could make to the code base real quick? Think again friend. You need a JIRA for that, you need to discuss the work to be done, it'll cause re-testing, you have automated tests? Well it might break something. Can't risk that, even though it's not in production yet... Funnily enough, our JIRA's were terrible quality too. Vague boundaries for the work, we spent literally 4 hours a day "refining" tickets, that took realistically less time to implement than the hours we spent discussing them. Massive refining calls with the entire team for those 4 hours. It was an "I&P" sprint, innovation and planning and it was 90% planning. One of their innovative ideas to make our JIRA tickets better? "mini" 3 amigos (this is in addition to the regular 3 amigos the ticket goes through). Before you pick up a ticket, have ANOTHER MEETING you MUST HAVE a dev, QA and a business person to begin the work. Because that 4 hour discussion wasn't enough. One of our "senior" devs got so blocked on doing work for the project, he enjoyed working more on side-projects than the real project. Wouldn't even seek out and try to do the "real" work anymore. It was such a disaster. But makes for a nice'ol horror story. It really makes you appreciate proper agile, tearing back all the nonsense, cutting the crap, having a team that speaks their mind etc. Makes a world of difference.
While I do agree with many of the points in this video, I have been in projects where this breaks down, and where meticulous planning up-front was imperative for the projects success. Specifically, I would like to point out the "the cost of failure is nearly zero" statement. For example, when the thing you're developing is responsible for billing millions of customers correctly, there's really no room for error. Not planning at all, releasing a just-about-finished version, and hoping to get feedback from your customers is not an option. That's a great way to get sued and/or get the authorities involved, and the cost of that is huge. Similar issues when you have to make sure the thing you're developing follows any contractual or legal obligations, really. Also, "It's the only thing that works" is definitely, provably not true. People were doing software development successfully long before Agile came around. Maybe just chose the best tool for the job, instead of claiming there's only one true way of doing things, eh?
I think we're talking at cross-purposes, let me clarify my statements in the video: 1. The cost of failure is nearly zero is true in an iterative approach, but false in waterfall. If you show your user what you are doing every week, instead of after 6 months, it doesn't really matter if they don't like it in the first week. 2. The folks that wrote the agile manifesto didn't really invent anything, they just documented what high-performing teams were already doing. I didn't mention it in the video, but the secret here is that "agile" is just the scientific method: Doing what provably works, not doing what doesn't work. So it's no wonder people everywhere were basically doing the same thing!
As a former agile coach I worked with and consulted many teams and individuals. You my good sir get a lot right, and it bugs to hear it, even though I preach it almost the exact same way. I was organizing internal "scrum basics" trainings and also conducted trainings in other companies for years and I always put a lot of emphasis on the theoretical side of Scrum and WHY it was created and WHAT problem it originally should solve. Scrum has nothing to do with estimations or velocity or user stories etc. All these things "parasited" their way into Scrum, making it de facto bad. No one today knows what a user story actually is, but it is such a common buzzword, that everyone needs to use it, or they are "doing a bad job"... That being said, you made a couple of statements to which I don't fully agree: * As per Scrum guide, Scrum meetings are not ceremonies, but events, and if your plannings, reviews and retros have no deep significance there is clearly something wrong with the implementation * Sprints are no framework for management, it is a frame to give the team a structured way of tackling "problems" (= making the product better), the frame consists of: understanding the problems and find a way to solve it (planning/refinement), implement it and keep each other up2date on the progress (Sprint and daily), review the work done on a product level (review) and review the work done on a interaction-level (retro) ** This can be seen by the fact that in daily only the team members are allowed to talk. It is NO status meeting, this is a meeting for the team to check which member needs help to do a good job. * Just build something and get your customers feedback is easy to say, but so hard to actually accomplish. Sprints are a really good start to do it. If the team is mature enough in handling this kind of process in a quicker timeframe, do it. But hear me out: It is beyond tough to do. As said, there are some excellent points in this video and it really bugs me that Scrum is being pushed into this management frame. Scrum is a product development framework. Estimations, velocity and burndown charts may be practices that many consider "part of scrum", but - oh boy - this just shows how little so many management people have understood in creating a good product today.
"Working software over comprehensive documentation" is good sometimes, but a more consistently valuable goal is to have a good balance between maintainability and immediate progress. It's the multi-armed bandit problem: "a fixed limited set of resources must be allocated between competing (alternative) choices in a way that maximizes their expected gain, when each choice's properties are only partially known at the time of allocation, and may become better understood as time passes or by allocating resources to the choice." (Wikipedia) However, I think agile forgoes this conclusion because of the role us devs often find ourselves in. The customer is always right, and if they requested something, they will get it. If the product they recieve makes no sense long-term, that's on them. They don't understand the code (they may not even have it), so at a certain point, if they want features, they will need to wait for the necessary refactoring. If the people who wrote the code are having a hard time maintaining /adding to it, then good luck finding a replacement who can do it faster.
I would like to say that LEAN manufacturing is the best parallel to agile software development. The Goal and The Phoenix Project are fantastic books, and they really focus on creating simple solutions for local problems. General, clear goals for software management does not really exist. I will try to make a pitch: 1. Increase throughput of releases which customers want 2. Decrease cost of features and cost of errors 3. Reduce WIP and dead code (this does not mean "do not write code", but instead, "do not leave features unfinished", and "remove code from production that does not do anything") I tried to replace throughput with lead-times of testable releases, but it just does not seem to make enough sense. If these are the goals, then the goal of any software development organization should be to "Increase throughput of features while decreasing cost of each deliverable during its lifetime while reducing unfinished features and unused code", and agile should be the method for striving towards that goal.
Several years ago, I found a decent metaphor for explaining software development to non-technical managers: it's not an assembly line, it's creative writing. No, seriously. Sometimes, our tickets are just correcting a typo, or a mis-ordered page. But most of the meat of our work is adding/removing/modifying entire chapters, or storylines, all while maintaining story cohesion and continuity. Now imagine that it's an entire series of novels, and you have multiple authors making large changes to the same book at once! I have still found plenty of terrible managers and companies that couldn't be convinced to give a rip, but some are willing to process that, and realize what programmers are expected to do
@@NoBoilerplate you aspired me to provide helpful content for other people (mostly narrow targeted tho). Great to see you grow. Maybe I will start my own channel when I finish my 20th meeting about changing api routes that we forgot to change in previous sprints. Frontend devs are also there btw) Great video, continue confidently)
@@lukivan8 You're very kind! I bet the auto-generated ones will be 99% right ;-) My scripts are here if that makes your job easier github.com/0atman/noboilerplate/tree/main/scripts
Great video Tristram! ❤ Having recently worked for a FinTech client that had a "Scrum of Scrums" in a JIRA Monster and hired _expensive_ "Agile Coaches" (people who don't _remember_ the last time they wrote any code, or worse don't know _how_ to code ...) to implement SAFe across the org, we _wish_ this video had existed and we could have shared it ... Thanks! 🙏
@@NoBoilerplate Yeah ... imaging spending **60+%** of your work week in meetings ... 😢 Try to explain to non-technical managers that meetings is not where the actual _work_ gets done. Totally Agree that "Agile is the only thing that works". Sadly, most people "practicing" Agile aren't engineers. Most people don't value the Engineer's time because they aren't _paying_ for it out of their own pockets ... Wasting an Engineer's time in endless meetings is _horrible_. Anyway, thanks again for making this video. ❤
The key is to find the balance according to your team and your product. The solution is never black or white. Methodologies run on agile by itself where you can iterate in order to have the best working methodology for you.
I agree with estimations, and the moral duty that if it's simple no need to plan it. We use estimations for stakeholders and for us to gauge relative difficulty. If this is a 3, and the next one takes significantly more work it's a 5 . If the next one has the same amount of work, but it involves other teams, other stakeholders, we bump it up. I mean these are heuristics more than anything. I don't care how management uses them. I value processes a lot. Should I spend all day writing to people in the slack channel reporting bugs on the website? Or should I have a workflow for them, to open a ticket, mark it as urgent or not, we pick it up, they can folllow process, they must fill in all fields to describe the bug. Retro if used properly can be used to get honest feedback, bring improvements and the team together, if it's not hijacked by someone else wasting time talking about a task.
The elephant in the room is that we need to change the way we work. I believe the creators of the Agile Manifesto aren't the first folks to come to the conclusion that we can do better. They called it Agile, but it's really just "stop wasting my time and let me get something done". There are a lot of folks that are working and don't understand what being a professional is all about. Our (in the US) educational system doesn't teach us how to think independently, it teaches us to follow directions. I find the most frustrated developers are those who do think independently and are not given the freedom to act on what they believe is the right thing to do. The various frameworks are there to help. You take what works and discard the rest. Companies implement teams but don't understand the purpose behind teams. The majority of companies are still working in a top-down hierarchical mindset. "I'm the boss, do what I say". People new to the workforce don't understand any other way and are trained to behave the same way, so as they move up, the next wave gets the same treatment. All with positive intent but terrible results. If you are a young developer/engineer, etc. you should know the Agile Manifesto. It was written by someone just like you, just after 25-30 years of work experience. Don't tell your Scrum Masters that Agile sucks, show them how Agile works. Build software, demo it to stakeholders, get feedback and iterate. Work as a team towards a common goal (not everybody working on something different) and get to know the people you work with every day. In my opinion, as a team, you should want to meet every day to understand what your plan is for the day and identify any impediments to your progress. Sprint review, sprint retrospective, backlog refinement - these are all things you should want to do and if you do them, the time is inconsequential. Why wait for a day or time to show your new working software off? Do it as soon as it's ready. If you identify a better way to do something, why wait for 2 weeks to talk about it? You should always be discussing the next things you'll need to take on. You'll need to do these things to get feedback and get better. Scrum gives you the framework, but what people rarely talk about is the adaptability. Take what works, discard the rest. When it comes to estimates, don't think of it as a prediction as much as a safety warning. You should think in terms of small pieces of work you can create and test frequently so you can get customer feedback. Estimation is an exercise you can use to consider what will be required to develop a piece of working software. The sooner you can show it off and get feedback, the sooner you get confirmation that the direction you are going in is the right one. The longer you spend before getting feedback, the harder it will be to change direction. Stop fighting Agile. Understand it and fight for what it really represents. You have a retro? Talk about what is really on your mind? What is NOT working and what do you want to change that will allow you to deliver working software quickly? Got a meeting that you don't want to attend? Is there an agenda? Do you KNOW how you are supposed to contribute? If not, can you decline? Are you empowered? If so, decline. If you get pushback, then you can discuss what empowerment really means. Are you assigned work or do you take work? Are you trying to get better? What would help you improve your skillset? Be an active participant in making you and your team better. Be curious and ask questions. Finally, there are plenty of metrics for Agile and measuring what a team produces. But are you able to easily show how often you deploy to production AND what you deployed to production? The majority of metrics are really for the use of the team to understand if they are improving. The only metric that should matter to management is are you delivering valuable working software on a regular basis (are the stakeholders/customers happy?).
"The only metric that should matter to management is are you delivering valuable working software on a regular basis (are the stakeholders/customers happy?)." -- This is 100 percent how it should be. Unfortunately, most managers come from a PM background and are addicted to charts. If they cant have their (gag) Gantt charts, then they want to see those burn down charts. If these people didnt exist we wouldnt need Scrum. XP would have been just fine. In my opinion, Agile was created to undo the mess that PMI certs have made. Only to have PMs transition to Scrum Masters and Managers and do the same thing they did before with bastardized agile terms thrown on top.
@@donparkison4617 IMO, Agile was created to get away from the manufacturing mindset. A group of people who didn't need to be told what to do got together and came up with a set of values & principles that anyone could follow which would just allow people to get the important work done. That was followed by frameworks because management didn't understand just values & principles. Then it became profitable to teach people and certify people and... well, you know where we are. I agree that Agile shouldn't be a thing. It should just be the way we work. If delivering value (and the most important value) early and often, not burning out your people or treating them poorly is important, just do it. You don't need a framework to make that happen.
Nice switch up of content! Would love to see some Obsidian content from you soon :) On the topic of agile: our team decided to change the approach from a more scrum oriented version too, we still have some meetings but are a lot more chill about doing meetings if we would rather focus on coding. Your point on the story points has piqued my interest, I might bring that up, because I really don't see much of an advantage in the numbers too, but TFB and NFC are good to mention on a user story!
One of the most interesting video i've ever seen. I've always hated SCRUM, and had become resigned to the (mis)idea that SCRUM = Agile, this video literally changed my mindset, thank you!
Elephant in the room no one addresses: what happens when the developers that were working in the project quit and there is no documentation and the code is a mess. Good luck being the one that has to handle that
Is pretty obvious and happens all the time because approximate time of a developer in a company is 20 to 24months. Blame Agile for being anti documentation, now teams need more meetings to verbally explain the same all over again to the new hires.
That’s always been the Achilles Heel of “purest” Agile development. “Let’s skip the func spec because Agile Manifesto!” Developer(s) split and there goes the project deadline with them… because client projects tend to come with project scopes and project deadlines - something else that doesn’t seem to have been considered in this sort of “it takes as long as takes” approach to project management.
@@BigheadGenius : Every coin has two sides- the spec needs to be met within the deadline, but sometimes the deadline doesn't allow enough time to meet the spec.
I agree at some companies Agile only got acceptance when it became waterfall by a different name. I think of Agile as a way for a team to find a way to work efficiently that suits them best. There's also a huge range of types of software that can effect the process of building software, e.g. mission critical, highly secure, massive scale, regulated / audited, entertainment etc.
I used to sit though 8 to 9 hour long planning sessions every 2nd Monday with the entire dev team and the entire leadership team. We produced absolutely useless software that none of our customers bought. Company collapsed. We all got fired. I have refused to do Scrum or "Agile-ish" ever since.
I'm sad you had this experience, I think we've all had some experience like this (maybe not the company failing every time). Faith in scrum in defiance of evidence is the insanity in many places. If you hear people calling something agile that doesn't make sense with the manifesto, call it out, they're praying, not planning.
I love this, thank you! I've stumbled into becoming a programmer using no-code tools and now I'm building software for clients. Since building software was a hobby and the no-code space is tiny and somewhat disconnected/ostracised from CS circles I have found it hard to understand how to take an idea from a client and deliver. Estimation and over planning is truly a killer. Thanks again this helped me think a lot clearer about all this.
The way I like to talk about it is that in most industries, the manufacturing of the product dominates the cost. So you need your plan to be right before you manufacture. In software, the actual manufacturing step is "hitting the compile button". It's so cheap we can't even value it properly. All that code you write *is the design* of the product. It's the blueprint, if you will. So, like almost everything else, we put a lot of effort into "getting the design right". But for software, because manufacturing is basically zero cost, it's far better to build it and test it with real customers than to iterate on design in the absence of a build (what traditional engineering does). The interesting upshot is that as simulation gets better and better, you see Agile working for more traditional engineering. Test the simulation, in actual use cases, and iterate with similar practices to Agile. Refine the design in a world where "manufacturing" is cheap.
Developing software equates to drawing the blueprint, not building the house. A design phase before building any software is like a design phase before drawing any blueprints. The construction phase for software is compilation, it’s very cheap, writing the code is the design phase.
Things tend to break in the middle. I’ve had managers that are process trolls and jira cult leaders. Surprisingly their projects turnout like dog💩. Micro managing knowledge workers is a great way to lose good knowledge workers.
Working software is #1, yes absolutely. Supportable, stable software is the second most important metric. And because there's almost always a phase 2 to any well built software, HOW it is written is very often important as well. As in, cleanly designed code written with an understanding that it will likely need to be extended handle additional use-cases. This is where product managers can make or break a project. If the devs go into it with an expectation that their current requirements are the only requirements, they will bake that assumption into the design. This can make phase 2 dramatically more difficult (and take a lot longer), as it may well require rewriting big chunks of phase 1 in order to accommodate the expanded requirements.
I was surprised to come across a video about project management on Your channel instead of Rust but I've enjoyed it a lot. I'm looking forward to more videos about IT as a whole. I'll pay more attention to how I spend my time at work. I'd rather spend it on developing software and developing my skills than wasting it. What I'll try using immediately is the idea you suggested in the comments. I'll try bootstrapping a new task by starting off with pair programming for the first 10-20 minutes and then let the assignee finish the task themselfs. As much as I'm willing to belive in the effectiveness of pair programming, it tires me too much to be forced to sit and code in a fixed time frame.
Other specific comments already, but wanted to raise bits I don't fully agree with and see what others thought. Sprint poker: If estimates show no consensus amongst developers, it's always worth asking the outliers why they gave those numbers. Can often uncover something the others had not thought about, or had and have a way to overcome, so reduces risk and increases understanding. User stories: Quick meetings done right us worked for us. Forces the business to realise they have not though something through enough (business version of rubber ducking lol). Sometimes they remove from sprint, or get the answers that were missing.
It's a nice story, but my experience is that outliers are overwhelmingly people who 1. didn't understand the work, 2. won't be doing the work, 3. Didn't care to ask for explanation before the poker draw. The value in explaining it to them is marginal, and feels like a waste of time to the other people in the meeting, who just expressed unanimity in their estimation.
I really want to know, what do the vast majority of "project managers" actually bring to a project ? Like, the vast majority don't even have a technical background.
I've worked with very few PMs who understood that software is DIFFERENT. The few that did followed the Manifesto's spirit, and had a very hands-off approach.
I would add that, while "working software" is important, working software that doesn't add value (eg, solve a problem, meet a need) is by definition valueless. You're not done when you release working software, you're done when the value exists (eg, problem is gone, need is met). Working software is your current best guess at what might provide that value, but it's not the point. It's merely a measurable, doable means to that end. Put another way, working software is a lead metric; value added is a lag metric. Value is what matters, but you can't directly add value: you can only directly make software. So make software. But if the indirect but actually-important value doesn't result, go figure out what software to make (or rework or some other non-software solution) until it does.
Scrum is a great tool if is applied properly and in the right context. I’m a SM in for a team of 11, working with other 8 teams on a large scale solution for the private operations of one of the biggest banks in the world. Now, think about the amount of stakeholders, strategic projects, impact of every change,the amount of dependencies and so on. In this environment, Scrum does for us exactly the opposite of what you said: it allows me to shield the team, reduce the noise and keep the team focused on what it has to be done.
I've also been in teams where scrum has worked well - the thesis in this video is that scrum is not a one-size-fits-all method, and I suspect the majority of teams using scrum would be better suited with something else
I agree that the overhead and ceremonies are an excessive veneer of corporate control. Nevertheless, those come from two fundamental realities: 1) businesses need to finance R&D and ensure return on investment 2) customers have timelines for delivery, so promised delivery dates are important for customer service So the "you're doing agile wrong" says to me "I'm an artist why don't people pay me for what I want to make". There's a bit of entitlement to the sentiment. Are there ways to bridge this? Yes, and it involves devs and product owners spending more time with customers and understanding what they want, and why they want it, and why they want it when... straight out of the horse's mouth. The dev team needs to be part of the feature bidding process.
We completely agree on the best way to do it right: Early customer feedback, straight from the horse's mouth. But estimating how long that best way will take is VERY difficult. Ask a poet how many poems they can write in a year, they will say "I literally cannot tell you" Ask a developer how many features they can write in a year, they will say "I literally cannot tell you". I'm not being entitled, it's just how it works, and anyone who tells you otherwise has something to sell you.
@@NoBoilerplate well my finance office will ask "how long will it take to build the feature or meet the requirement", and the customer will ask "how long will it take for you to keep your promises".... ....a poet can shrug and say that "I literally cannot tell you" but then both the board and the customer say "well then I literally cannot pay you." ... and that's before CyberSec run a linter over the code and CICD pipeline and insist that it has to be fortified before it's suitable for Production deployment.
@@cassiuslives4807 I don't doubt there are ways to give estimates to those people, both time and money. The agile manifesto does not say anything about that, and cramming in estimation into it causes a great deal of problems.
This might be the most succinct and illuminating explanation of the issues on this topic. Which is even more amazing considering the portion of time devoted to crediting another person!
Thank you so much! Ken from CTTM and I started at about the same time, and so we connected and did this little shout-out swap! It's such a nice community!
Scrum is a terrible trap to end up in for most organisations. The issue isn't scrum directly. But rather that its not meant to be implemented organisation wide in a fixed manner. Agile isn't a process, its a methodology to approaching software development in a dynamic and flexible way. The issue is, Scrum takes the inherently reactive approach of agile and applies a very traditional pre-emptive narrative to it. You can't plan your way out of chaos. You need to have a goal in mind and drive towards it in as small steps as possible. I'm a huge fan of XP practices and applying periodic goals to a kanban style of working. The way I see it, you need to have three things to be effective in an agile enviornment: 1. an overarching goal for the next 3-6 months (Some idea, some technical principle, some project vision) 2. a rough plan for the next couple of weeks (some chunk of work, like implement caching, redo front end rendering etc) 3. willingness to scrap almost everything Without that, you have nothing. You need goals, and targets, but you need to accept failure is part of the process. You implement idea x, move on, if X is no longer fit for purpose you redo it.. SO, you have a goal -- some new project, you have a very rough idea of what it needs to look like, you start throwing things together, POC's and spikes etc. just do it quick and dirty. Then you take look at what works, whats broken, whats horrible to look at, work with etc, Then you two together a rough idea for what needs to be replaced or redone. you have three categories: 1. Now 2. Next 3. later You don't score, you don't estimate, you say, this is now, this is next, this is later, If management need estimates, you say now = small, next = medium, later = large. You don't do anything too large, you look at work, see if you can implement it, break it up if not, But that's it. every time you finish a few tasks you bring in the next piece of work. Heck, you can make it so you don't pick up more work until the entire team is finished if you want to avoid true kanban,. but you should just try and implement stuff. Jira is a brilliant and a terrible tool devs. Its great for keeping track of what you're doing, but its often a anchor. Jira should be used simple to keep track of whats being worked on. Nothing more. Maybe for AC's or bug reporting. But that's it. Test everything. but avoid massive UAT servers and test environments, Try and avoid regression tests and integration tests,. You want to keep testing light, fast and effective. Next time someone mentioned Scrum certs or agile coaches, run away. push back as hard as possible,. you don't need an agile coach, you need to just start being more active and more deliberate. pragmatism is the key here. Oh, this solution works, but will likely break at 10x the projected load, unless you know you'll ever hit that, just implement it. move on, refactor and replace later.
@@NoBoilerplate the wild thing is, it didn’t need to be like this. Developers have done this to ourselves. We’ve pushed and pushed from agile and Scrum constantly for decades trying to move away from waterfall and have allowed agile and scrum to become synonymous with each other. We’ve allowed for our goals to be more autonomous and efficient and reactive to be co-opted by middle management and project managers. And we can’t blame them. The only real solution is to break down the barriers between product and engineering and really make it clear the processes needed to deliver a solution. Hilariously, the most effective and efficient team I ever worked with was a full on waterfall team. It’s wild to think, but they were genius. They managed their roadmaps like series of micro waterfalls and planned everything to the limit. But in tiny tiny chunks of 3 weeks. It was wild. But, I don’t think that approach would work in most cases.
Informative and good as ever. One little suggestion if I may: why don't you add the numbering to the video title later on. I think it'd be better for the algorithm if people didn't think each video was part of a series (which they kind of aren't since they have self contained topics)
Big teams can respond to change fast, in my case we're 2 devs and we should have planned from the start, but that did not depend on me and we're way overdue since changes take long
I follow your very useful videos and I also follow Allen and Dave and Martin. I do dislike Scrum, Ceremonial Agile, SAFe (ugh!), and more than anything Jira and certifications. There is one way to learn and do Agile: Do agile! And there is one way to learn it (besides doing it): do it with people who have done it before and successfully if you are lucky to be in such a team. BUT, one thing I guess we overlook is the FORMAT. In the long term, Format is more important than Content! That is why religions with rigid ceremonies last and liberal approaches to religion ceremonies die. In software design, this is projected in Conway Law. Maybe, the only design law in software that I am aware of. It is important to have simple but (kind of) rigid formats, processes, chart, team formation, communications, version control, release cycles, CI/CD in order to have a successful product for a very long time.
Most of the time when someone blames scrum or other frameworks, it's not the fault of the framework, but the companies/managers. for example: having to much meetings when spending one to two hours a day refineing and estimating is not part of agile. in scrum it is the responsibility of the product owner to refine, that developers can work efficiently. estimation is not required. but most people think it is part of scrum and blame it for, then in fact it is not. you don't need to do that if this is not fitting for you. working more agile should never be a overhead. it should give you more. more feedack. more transparency, clearer storries, and than: more (quality) time to code and not spending an hour figuring out what a story with only a title should mean, and doing it twice because you misjudged. keep focus what you realy need to do, to be agile, and stop blaming scrum for companie specific decisions
7:30 Please correct me, if I'm wrong: Does that mean, that you should never write comprehensive documentation, because that time could be better spent writing more software?
Sorry, I see I wasn't clear, I should put this in the ERRATA comment: I love code documentation, api docs, etc what I don't like is process documentation, overhead documentation, all the stuff that literally doesn't matter if you don't do it.
I do agree with most of the points on this video, but I can’t seem to understand the “do not plan tasks and don’t estimate them” I am a software engineer that wants to not only understand what I’m gonna be working for how long, but most importantly when can I expect something else to be done for me to continue it. And I don’t believe pair programming or always asking is the answer here 😅
To be clear, I only said don't estimate. When planning takes less time than doing the task, there could be value for your team, for SURE. It's when planning takes longer than the task that I get frustrated!
I'd very much appreciate your perspective on how to address nonfunctional requirements in the context of agile (or whatever) development. I'm a security guy, and it's really hard to sell customers, or even other engineers, on a "feature" that just consists of "stuff not breaking." That's applicable to security in particular, but also in general to reliability concerns and architecture work, as well as handling technical debt. Usually the customer can't give useful feedback (because it works fine if they're not pushing to prod, and ideally all they see is things not breaking), management doesn't understand why it can't just be handled in the same style as acceptance criteria, and engineers don't want anyone bloating their tickets' AC with things they can't directly test for.
I understand, I worked for a year and a half in one of the uk government's cybersecurity departments! You must have buy-in from the top. Ideally before the breach, but when it happens, THEN you make sure you get it.
I’d absolutely love to roll back the cruft and plan less, it certainly sounds like the way. The main problem (in public sector anyway) is the PM who needs to report the project progress to their bosses. Whilst there’s many ways to do this, they almost always fall back on sprint burn down, which requires all the other planning junk to work, so it gets done as a necessity prerequisite. Still sucks though.
I worked in the uk's Government Digital Service for 4 years, finishing only recently, so I feel that! My advice would be for the PM to focus on larger features, demoable outcomes, rather than tickets. %age through a certain releasable epic, perhaps.
@@NoBoilerplate agree! Show progress through showcases/demos, whatever they’re called it’s not important. I will continue to fight the good fight, currently trying to convince the org to not do ‘backlog grooming’ on day 2 of the current sprint…..
Fully agreed that too much process and ceremony can be detrimental to progress. But on the other hand, in my humble experience, certain tools, agreed upon ways of working, documentation, feedback from both customers and from peers and some ways of making sure devs and dev teams aren't working on duplicated, competing stuff or some stuff that should be cared about goes without caring are a must. So is connecting all that jazz to the other parts of the organizaion. On the other hand I'm all for competing prototypes, but we should have everyone commit to the one with most long-term merit and coherence for the overall solution. Too often I feel like "being agile" is used as an excuse for not doing any planning and not coordinating work with the company as a whole and all sorts of unmaintainable gung-ho short term hacks that screw you over in the long run. I feel that there's a lot of good stuff built into Scrum and most of the events seem to have a valid purpose. I would be very interested experiencing a reasonable implementation. I have never witnessed Scrum in action myself.
'being agile' does indeed tend to cover a multitude of sins - I hope you've seen I'm arguging for an evidence-based approach. If scrum works for your team, great! If a heavyweight process works, great. It has to WORK for you - there's no one-size-fits-all, but there doesn't have to be.
@@NoBoilerplate Thx for the reply! :) Working as a mixed IT admin and software developer for a programming house that also does electronics and device manufacturing and very much doesn't forcibly restrict your role inside one particular box sure puts a whole lot of spin on thinking about these matters and grants an unbearably wide perspective on many types of issues and viewpoints. I try to think about it all too much for my own good, but hey, being holistic is a good thing right? And it sure doesn't get boring. Now if only I could grasp all of it or at least the most significant parts from all over the biz and make some concrete good come out of all the pondering and wondering :D Or die trying. Work in progress.
I love the message, and couldn't agree more about agile. Management often look at scrum and safe as this prescriptive cure all and quickly lose most of the value out of their developers by bogging them down. I do have a nitpick with the idea of not estimating and by relation; sprint planning. In my experience, there is great value in communicating with the team on what everyone is planning to build, and the outcomes they hope to achieve. This helps limit waste if we are actually iterating fast. Most of all, I value the information the team learns together at the end during a retrospective. As for heavy tool usage, large companies in the US have a lot of conflict actually working this way, especially public ones. There are many metrics that have to be tracked for audit and tax purposes, and the overhead caused by tools are used to (hopefully) automate that tracking. Not to mention the need to track and plan for large releases across the enterprise's projects.
Regarding the documentation, I agree that good code is self documenting. BUT as soon as you leave pure development and enter the realm of DevOps and need to deal with Operations then documentation is a must. Especially if you need to do 24/7 and the skill level in the team varies.
I have more than a decade of professional experience and I'm yet to work for a company that is not doing "Agile" the way every developer hates it (bazillion of meetings, estimations, poker planning, 2 weeks sprint, etc.). It's gotten to the point where when I see "agile" in a job description, I just close the tab and forget about that company. I'm 36 and I've never worked in a truly agile company. Depressing.
Hey! We're the same age! But yeah, it's SO rare. I worked in a Thoughtworks-run company, and it was KINDOF good. Pairing, and lightweight scrum. But the CTO still screamed "WHEN ARE WE GOING TO MAKE THE PRODUCT" half way through another 2h meeting once. That was funny.
This is without doubt one of the best things about agile I’ve heard in a while! Thanks for putting the word out there!, will look at the source for the inspiration too!
I think this is a model that makes sense in the context of a piece of software being built collaboratively with a customer as a service, which is frequent in spaces like web development, but starts seeing some major friction in software written as product (eg video games). Software as a product needs to be able to sell itself, not just meet needs. It can never meet needs if it doesn't get bought. We can't go back and forth with our customers until we have customers. We do what we can to estimate, and simulate, customer feedback. But at the end of the day we have millions of customers, we'll only ever hear from a vanishing fraction of them, and mostly after we've already finished and wrapped a product. And in games especially the meaning of "working" has significant logistical overhead to even define and measure. What is working code when the only measure of working is "fun" that has to fit into a multi hour, sometimes multi month consumer context?
A common problem - I believe the common solution is using a "client proxy". If you can't get the client, then get a simularcrum - product owners, or game lead designers or testers etc. I totally agree that it's a difficult problem, and I'm not suggesting any other solution than to start with the manifesto and build up from there. A game dev studio shouldn't just use scrum and hope!
Nailed it! No scrum, build/deliver direct to end-user - great, but in my company, engineers are shielded from the end-user by a layer of technical management. It makes it this much harder to penetrate this bubble.
F**king hell I watched this video 4 times in the last three days and I cannot express how hard this video hits working for a company that is a contractor for a company that wants us to work in a SaFe environment. This summarizes all issues that we currently face and the reasons why this is not working Thank you!
Another good quality video from No Boilerplate, I love the fast-paced data dense videos no matter the content of it. I believe I watched another video from another channel which shouted you out too for this, just nice to see your way of doing things is getting known.
Re: the house building comparison, I think the reason a traditional plan-meticulously-and-them-build approach doesn't work well in software is that software development *is* mostly planning to begin with. Meticulously planning software ahead of time can be like making plans to make plans. That's not to say there's no place for planning in software though; for complicated systems having a plan for the general architecture of the system before you start implementing is probably always a good idea.
Most meetings I put together as an engineer, people walk out commenting that it was productive and they got something out of it. Most meetings the scum leaders put together is met with exasperation and thought to be a waste of time.
This occurred to me for the first time while pausing to reread the manifesto bits at 1:15. "Individuals and interactions over process and tools." Scrum (which isn't agile, I know) and how it has been implemented at past companies is almost exclusive process and tools.
I like this. I feel agile, or the perversion of it that companies today believe is agile, is something we need to have a sober discussion about. I feel it has become "tell teams to do X" and the core values have been forgotten. Just like you say, the teams are supposed to figure things out as they go so their solution fit in their eco system and with their knowlege and challanges. With that said I do believe Scrum (which made a concious decision to move away from ceremonies to events) can faclititate successfull agile development when working with complex problems. But Scrum is incomplete by design. It only "mandates" the core aspects that are needed for the feedback loop and continued learning to take place. The problem is that several things not part of Scrum have become what many believe Scrum is. Burn down charts, story points, valocity... and on and on. Sure, if they help your team in their work you can use them, but they are not mandated by Scrum... but sadly they often are by management. Which by itself is an indicator that the plot of the entire thing is lost to the organization.
OMG, you nailed this on every point. Thank you! There's no telling how many days of my life I've wasted in daily stand-ups listening to people try to make it seem like they were productive since the same time yesterday. The micro-managers just love it. And out of all those thousands of meetings, I would wager I've heard something useful in maybe five of them. To management, Agile is synonymous to Scrum, instead of Scrum being a subset. I would like to try Kanban, but no one seems to know what that is. And the Scrum process becomes the new religious dogma. You estimated more hours of work than remain in the sprint because something is taking longer than expected? Oh No! The burndown chart is now in the red! You better work late to fix that for the arbitrary sprint deadline so our retrospective charts look pretty! This shit has really ruined my love of a career in software development. I currently work in the defense sector. You can imagine how bureaucratic any process becomes in an industry that's tied so close to government, the epitome of inefficient "process". I can't wait to retire.
That sounds tough my friend. See if you can get into a smaller, younger company, and in the interview ask them how many hours of meetings they have in a week. If they don't know, thank them for their time.
I've seen a couple of places do scrum and agile and what they've all failed to do is iterate. Developers work twice as fast and are 10 times more enthusiastic when they have a rough crappy prototype of the final product. If the choices are "A crap prototype in 2 days" or "A nearly finished product in 2 months", I guarentee the crap prototype will turn into the finished product in way less time.
Really good to see you promote "Code to the Moon". There are some poor quality content creators who upload videos that cover nothing other than the Rust docs. On the other hand, both of you upload really good content that resonates with me, as somebody who has been working as a software engineer for almost a decade. There are real, enterprise concerns being mentioned here.
I really like your videos, but this time I feel the need to write a comment because my jimmies are a bit rustled. First of all, I 100% agree that what's currently out there in the industry has long stopped being (or never was) "Agile" in the original sense and instead is a bullshit marketing term for management, making things worse than better. That being said, i doubt that just following the Agile Manifesto is enough to lead us out of the software development process jungle. - The reason the Agile Manifesto has survived for as long as it has is because it is not really actionable (and that's ok, its purpose is to outline the fundamental values of agile work). - Even for pure software projects, people struggle to translate the Manifesto and its 12 principles into actionable steps for the trenches of the software development industry. Even the most fundamental question, "what is valuable?" is extremely hard to answer and "involve customers" is only the beginning. - Many software projects (I'd argue the vast majority) are entangled with domains that have longer cycle times like certification, electronics, hardware etc. requirements and constraints are coming from. - I don't know what "working software" is. Is it when the customer is happy? Is technical quality part of it? Maintainability? I don't want to sound unfair because it's a 8 minute video which can't just solve a methodological question of the past 40 years. I guess what I am trying to say is that we are still far away from a methodology where we can say "do that and you'll get a good software product".
Thank you for your comment, good to chat - I totally agree, my video mostly points out what is currently not working, rather than provide answers. The FIRST STEP is to realise that scrum/kanban/solid isn't the only way to do it - the way to do it is to start with your exact problem and domain, understand the agile principles, then work your way up from there. As you say, if you're bound to long lead times or hardware or government policy, you will work your way up to something that builds those immutable foundations in. But you'll never know if you don't start from the manifesto and work up! :-)
The pushback I frequently get is that we are singing external contracts with people who expect and thing by a date. We can't really get a 5% contract signed see how it goes and iterate with this people. How does one agile in that environment?
A great question, I don't know the answer to that, and the Agile Manifesto does not pretend to either. Agile is the fastest way to write correct software, but sadly, as I said in the video, it does not produce deadlines. We can only know that we are writing software as fast as humanly possible, to the customer's exact, and changing, specifications.
@@NoBoilerplate Currently looking into this, should be really fast from a User point of view as they are moving more to server side rendering. If you get around to look into this, I would love to hear your thoughts, Thanks!
I was with you till the end "The user's definition of working software" is the thing that minimally does what they want. For which the blame when it doesn't do it excellently and securely will fall back on the developer. Seems like a raw deal.
"the blame when it doesn't do it excellently and securely" Sounds like the user DID have definitions of security, they just didn't articulate them. We as developers know that there are many implicit expectations of software, security being one. Part of the job is looking ahead at the things the user will eventually realise they need.
I'm struggling to see what the answer to the question you posed actually is. At 4:32 you pose that what agile is bad at is answering the question "When will it be done?" and that the "People with the money want the answer to this question." This is completely true in my experience! However, the solutions proposed are "Don't estimate" (5:12) and "No sprints" (6:34); you dig into why these could hold a team back (with which I largely agree) and discuss that we should "Get feedback from a customer as early as possible". What I'm not hearing, at least not directly, is an answer to the question you posed. Yes, we can remove waste from processes by not estimating and by not having scrum ceremonies - but how do we tell someone how long a piece of work will take? I'm by no means a scrum advocate and I'd happily do away with estimates / ceremonies to improve the effectiveness of the teams I work with, but I don't understand how this translates to satisfying the needs of customers who want to know when we can deliver something.
I'm sorry Adam, you're not confused, I indeed did NOT propose an answer to the "how long will a piece of work take" question. In my experience, nothing answers that question reliably, so we invent processes that look good to management.
Exactly. Read the manifesto and don't use the the shorted version with only bullet points like "working software over comprehensive documentation" that are so easily misinterpreted wrong.
Pretty clear but I have to disagree regarding the documentation, at least the internal documentation. - First the domain can be complexe and you cannot expect people to go through implementation detail to understand the complexity. As an example, AWS has some great lib with good documentation but some of the core concept need higher level documentation, containing illustrations and stuff. Introducing new comers to a complexe problem through a code base is utopic. - Second, the code base is the final iteration of the product. It does not contain the information related to the previous versions, why it evolved the way it is today. Having an internal documentation explaining the rational between the implementation of a feature is crucial, otherwise it will be lost and create endless debates. I agree it’s a lot of time invested but IMO, it’s worth it at an extent. Note regarding sizing: don’t be fool. The main purpose of sizing is for managers to compare developers’ velocity. However, it also helps to spot potential divergence regarding the complexity of a task, which sometimes reveals some unsuspected consequences of a feature.
Junior Java Engineer here, I’d say that at a lower level i don’t have many meetings, in fact most is over messages until it gets to a discussion of more than two. Cant say i’ve had any unnecessary meetings… maybe it’s luck, or maybe i’m not senior enough to be considered worthy of them ahah
scrum is nothing, wikipedia can teach you scrum: "Scrum prescribes for teams to break work into goals to be completed within time-boxed iterations, called sprints. Each sprint is no longer than one month and commonly lasts two weeks. The scrum team assesses progress in time-boxed, stand-up meetings of up to 15 minutes, called daily scrums. At the end of the sprint, the team holds two further meetings: one sprint review to demonstrate the work for stakeholders and solicit feedback, and one internal sprint retrospective." Learning what WORKS for software teams is very different. The Manifesto works, but doesn't prescribe very much, and that is because it's very different team-by-team. Scrum might work for some teams, kanban might work for others. I'm sorry that's not the answer you wanted, managing artists (which is what software developers are) can't possibly be the same in every team. But I do have a recommended reading list for you: holub.com/reading/
The hardest part of software development is the struggle with capitalism. Your employer is attempting to maximize profit for leadership. You are trying to write good software and the two goals are often diametrically opposed. You have to be willing compromise a bit if you want a paycheck
I agree with a lot of your premise but not necessarily your prescription. Over my career I have fought and fought with people who do half assed scrum and use Jira and stand ups to micro manage developers. So really, the motivation of the leader of the dev team should be to protect the team from micro management and unrealistic expectations. If the motivation of the leader is to impress his/her bosses with cool metrics the whole thing is doomed. Scrum is just another stick to beat people with at that point. So if the team lead / manager has the right motivation, how do they protect the team from PMs and C suite nobheads? Thats what velocity & capacity are for and you cant do those things without sprints or estimating. Here is another place where this often goes wrong. When managers (usually those PMs) insist on estimating in hours instead of story points, or even worse they talk in story points, but equate them to time boxes. When I see a team estimating in hours or time boxes (other than the sprint itself) and its obvious their process sucks. They are trying to make good burn down charts, not good software. The only reason story points exist are to compute a velocity (average story points per sprint) in order to calculate capacity (Velocity adjusted for availability). And the reason capacity exist is to protect the team from overwork, micromanagement and an unsustainable pace being forced on them from on high. This is the team's capacity. That is all they can take on this iteration. And if you do it right, you leave room for refactoring, testing and innovation in process. Here is another huge red flag. If you hear anyone wanting to 'increase team velocity' or compare teams against each other using velocity, then you have managers creating unsustainable pace. And what happens when we work at an unsustainable pace? Our code sucks, I.E. we have broken the cardinal rule by putting the process over the software. People being forced to work faster, inevitably introduce more errors into the code and innovate less. I always say, never confuse the Artifacts of work for Actual work. BUT, you need some number of artifacts to show to the people paying the bills that working software is being delivered at a reasonable rate or to estimate when a certain number of important features will be delivered. But this isnt really for them, its for the team. Is so managers dont feel the need to dive in and get in the way by trying to 'get the project on track'. That is always a disaster. We all have lived it. But after all that, if you have the choice to do True Agile, where story points, estimation, sprints and velocity dont exist because you dont have to report to people who have no understanding of how software is built, then great! Maybe you work for yourself or a cool startup that gets it. You enjoy a rare and wonderful place. But thats not the world most of us live in. The best we can do is create a shield around the team so they can do work in as close to an agile way as possible. That is what scrum is supposed to do. Give management enough information to not panic and to leave the team the F**k alone.
The problem with removing estimates is that it's impossible to provide a cost to build a product or a time frame to release a feature or patch. Removing estimates is awesome if it's a team dealing with new verticals in an established company, where building a strong foundation is more important than quick delivery, but otherwise a nightmare for managing clients. Also, in my experience, removing estimates and responsibilities does not mean better code and products. For bad developers, it just means the same quality taking twice as long. It is the old case of good developers paying the price because of the bad ones.
I see what you mean - I'm not suggesting that there's NO place for cost estimation - but that the developers should spend only minimal time in meetings about it. Where does that leave estimation? Elsewhere, I think.
FALSE. If your user stories are all roughly the same size then over time you should have plenty of data to confidently give an estimation within a standard deviation or two.
Majority of IT seems to be closer to plumbing and other construction related work nowadays: there’s a goal, the are limitations and some unexpected issues along the way, but for some reason IT folks consider that not having a plan, ETA and risk awareness is fine and clients should have no issues with this.
What you described assumes that you have a team of highly capable developers. In the corporate world you often don't have this and hence why you need guardrails.
Agile is great in certain circumstances. However, in some cases, building software IS like building a bridge or a house and detailed planing IS necessary. But in the software industry we a fad followers. New framework, cool. New language, awesome. New management process, sure. And we do this without ever considering if these things make sense for the TYPE of project we're working on.
I'm not saying agile CAN'T scale up to building bridges, in fact I'm saying it absolutely can - I work in the UK's Government Digital Service - we use as lightweight processes as needed. On billion/week payment processing systems, you better believe it's heavyweight with change-request etc, but when we needed to roll out the covid tracking app, we did that shit AGILE. www.gov.uk/service-manual/agile-delivery (my opinions are my own, to be clear) 'Agile' is just responding to reality. Totally agreed that reality occasionally needs heavier weight processes. But it should be as light as possible.
Were being taught agile through scrum, where I'm studying CS, but I've often felt that it was impossible to estimate tasks that involve technology you haven't even learned. This has lead to us ditching most of the ceremonies of SCRUM, and instead focusing on getting work done. This however lead to another problem, where the less experienced members of a group end up stuck, confused and/or left behind, since they rely on a lot of the planning for certain tasks, in order to break down the given problem. So as a student I feel kinda stuck between these ideas. Any ideas on how to handle such situations, and what is your opinion on agile development from a students/learners perspective?
I wondered how schools were handling this, since agile wasn't really a thing when I was in school. Hell, we never covered anything about managing / planning large projects. It was always just one-off programming assignments. Actually thinking of my first real job after college, we basically did a simple "agile", it just wasn't called that. We'd have meetings when necessary to plan stuff and go to work. We'd have impromptu meetings whenever needed to clarify issues or ask for help. It was awesome.
ERRATA
- The cost of failure is only nearly zero if you iterate quickly. If you wait 6 months to demo it to your stakeholders, well... you get what you deserve.
- I somehow got NFTs and NFC mixed up. What a shame, it's a halfway decent joke otherwise.
- I realise I didn't mention what I recommend. I'd start with:
+ A 5-minute standup in the morning
+ Around a kanban board
+ With a WIP limit of team size/2
+ Demo as often as you can
- NOT ALL DOCUMENTATION IS BAD, sorry I wasn't clear. I love code documentation, api docs, etc - what I don't like is process documentation, overhead documentation, all the stuff that literally doesn't matter if you don't do it.
Why the WIP limit? Do you think that each issue should be worked on by at least two people? Why not WIP limit
@@TobiDub Pairing is really, really good.
@@NoBoilerplate I've heard so much good stuff about pairing, but as an introvert I find it exhausting and the opposite of fun. What I love is diving into a challenge, grokking it, solving it, then sharing it for review/discussion. Pairing (for me) is good for knowledge transfer and overcoming real blockers, but otherwise I want to play music and code by myself.
My limited experience is mostly solo projects that are quite detached from other current work. In that case I would still say do the standup just in case there is the possibility for knowledge sharing. But also a weekly +-30min meeting with whoever is in charge of the project your work is attached to. Keeps everyone up to date and it is nice to have some fixed time to look at what the ideas/issues are.
Never skim on documentation though. Even if it is the basic stuff, someone who is new to the environment you use will thank you for it.
@@LoveLearnShareGrow extremely relatable - try using a 10-minute pairing as a kick-off on a task. Get going with help from a friend, then do the rest of the work solo
At my last job, I let my manager know that I felt that we were having too many meetings, and he told me that he valued my insight, and scheduled a meeting to discuss the matter.
I've started asking at the top of a meeting "what would happen if we didn't have this meeting?"
Same, i've finally left my job and landed another one with twice bigger salary and it's not so annoying yet.
Wait this literally happened to me and I thought it was strangely a waste because the urgency just dies while we wait for that appointment.
@@NoBoilerplate I like, "By the end of this meeting, we will have"
We should all reject meeting invites that don't describe the objectives of the meeting. The "How the world will look different after this meeting" approach is good.
I worked at a place this summer and by week 2 I got my manager to completely ditch sprints and stories. We had a small team of 3 and just had a list of tasks and just took the highest priority issues. When someone got stuck we did pair programing. Probably the smoothest and fastest working project I have ever worked on. Really hate all the ceremonies involved in scrum
This is the way.
This works because you're 3 people. Grow to 8 and it will most likely fall apart unless everybody has the same knowledge/seniority and way of doing things (which is rare).
@@Winnetou17 there's no limit to the team size when it comes to working with Kanban. Why would it fall apart?
@@strangnet Ever heard of the "pizza team" ?
Also ... the more tickets in a single column of your Kanban, the harder it will be to make sure you don't forget anything
Getting stuck and pair programming with somebody in the team is always such a fun bonding moment.
I prefer "briefings" over "meetings", if that makes sense. For example: we were considering moving from RIBs to an architecture optimised for SwiftUI, but we weren't sure which one. The initial meeting to discuss this matter was pretty much an hour wasted. However, a senior engineer ended up implementing every single viable option within our existing skeleton -- the briefing to explain his findings took us to a conclusion within twenty minutes.
Very nice, I don't hate that - I also dig 'kick-offs' which sound very similar
I was at a company one time for about 2 1/2 years. We had a scrum master whose job was basically just to waste everyone's time organizing scrum meetings and install and manage processes. We had a 6 month cycle that went like this:
-New scrum processes/set of meetings gets announced
-Everyone tries to follow it for about 2 weeks and then anxiety due to lack of productivity began to build
-Every starts quietly ignoring the processes as much as possible to get work done
-Productivity eventually grinds to a halt, disasters begin to mount
-By month 4, we're in full-on firefighting mode. Everyone completely and totally throws all rules out the window, stops giving a shit about anything process-related, and just starts working and getting shit done.
-By month 6, the smoke clears.
-New scrum processes/set of meetings gets announced.
I recently re-wrote a piece of internal software. It took me about 4 days of prototyping, then actually doing it. Then another week of testing. After two weeks, yi told my boss about the re-write, and that it was done and now working better-than-ever.
Had I asked about the project beforehand, the planning phase alone would have taken a month
Sneak in XP
Hence one of my favourite expressions: "It is easier to get forgiveness than permission."
Working in video game industry, I can say that for small teams, you might be right. But for large-scale team with limited budget, deadlines, changing scopes, and large number of people from various disciplines, "over planning" is kind of necessary.
Totally understood. My video isn't to say that I am smarter than a million software companies doing things with heavyweight processes - but that it's important to question the one-size-fits all approach. I'm advocating starting from the agile manifesto and working up. In many companies you'll reverse-engineer sprints, and that's fine if that's what works at your company - but I bet it'll be more custom.
On my team I found it was insane we were pointing issues that take less time to solve than the time we spent in that meeting pointing them
get mad!
@@NoBoilerplate I actually tried that, it did not end well. I was fed up with the amount of time we spent in meetings yelling at each other about how things sucked instead of working on solving the problems. Suggesting that picked the people that could (and should) solve the problem and move forward resulted in more yelling.
BTW: The term "planning" needs some explanation. There is the planning where people estimate time and drag things out on a Gannt chart, and then there is the planning when software engineer(s) look at a problem and determine how to break it into manageable parts (often creates an architecture). The first is useless, the second is critical.
Some people treat the "no planning" approach as if people should just start typing out code on a keyboard; this rarely works. I find that there is a big difference between "coders" and "software engineers"; coders write code, software engineers solve problems using and writing software.
@@CalifornianViking exactly right. Love planning. Hate estimation.
@@NoBoilerplate Scrum Master here with a genuine question, without any estimation, how can a company assess volume for client expectation setting on large scale projects? Like most companies, ours wants to continue to grow, so we are always lining up new projects, but without estimation one could overfill the pipeline and ruin relationships due to a failure to deliver within a reasonable time frame.
Generally my guilds have placed the focus on being close with our estimates (we use story points, so ideally within 1 deviation up or down) and focus on learning about what questions we can ask or what discovery we could have done if the difference is significantly larger. In our planning we don't spend much time on the estimate itself and instead focus on making sure whoever is tackling the work has as much info as they need to feel comfortable with the task.
I understand the pragmatic desire to mitigate superfluous meetings and try to safeguard that for my guilds, but those I hear being proponents of an estimate-less, and status meeting-less environment I don't feel are considering some of the real business necessities outside of the Dev dept.
Also, how would a company set a budget for a project without a relative understanding of the effort, personnel, and time required to complete it?
Please don't read any of this as snark, it's me genuinely trying to improve my game to better support my guilds and understand divergent view points.
@@benmerk4086 Hi Ben, you sound like one of the good ones, I've had the pleasure of meeting many in my career.
My problem with estimating individual stories is that my feeling is that the bounds for error are well over 100% due to the extra stuff that happens during a sprint to get work done. Undiscovered problems and hold-ups, or the other way, with work that is surprisingly easy.
Estimation at the story level is what I have a problem with, because it seems to me to be just as good as top-down estimation. And top-down estimation doesn't take up any of my expensive team's time.
To be clear: story planning and kicking off I'm down with, seems useful. But estimating time or effort? That's a much more dubious value proposition for me, after 15 years of developing. 1/TFB/NFC might me 90% of the way there ;-)
We shared this video in the company and I talked to the dev team I work closest with if we should change anything, drop any meetings etc.
They unanimously said that all the meetings are needed and that they really like the way we work. We are running 3-week sprints and do a production release after each sprint and the team likes that we can cherish the progress we made together.
But in turn we keep all other meetings to a minimum: We only meet when there is something to discuss and make sure only the people attend that are involved in the agenda.
Team likes it, customer likes it therefore I like it 🙂
YES dude, that's great to hear. Sounds like you're doing the right thing: Checking in on the process, asking if it needs tweaking. Nice!
Corporate agile = several waterfalls happening simultaneously while not being able to find documentation divided in 50 pieces stored in 100 different places
yup!
Even worse because waterfall has some phases which are usually omitted in the corpo Agile but they are crucial to get the work done
Oh, and some pieces are replicated thrice or more with only one of them being up to date.
corporate agile is the opposite of real agile.
Your point on estimation is a breath of fresh air. I always hated being asked to estimate how long something would take as I really never had a clue. Then I started following the advice of "however long you think it's going to take, double it" and all of a sudden people are asking me why everything is going to take so long. I don't know!!
The sad truth is that all these ceremonies are overhead and add no value, we all know this but go along with it and it takes 50% of our time.
if you keep estimating things, and you still don't have a clue, it's probably, because you really don't...
Yoooo agile??? This is not Rust and I LOVE IT!
Mixing your regular Rust content with other smart stuff is really nice. Keep it going!
oh what a RELIEF! This video is such a risk for me, I've got lots to talk about around technical topics and I want to get to them! Thank you :-)
@@NoBoilerplate Poggers
@@NoBoilerplate I think you should realize fans like myself atleast… really appreciate and respect your knowledge on all things not just rust :)
@@albo4life6082 Thank you so much for saying so 🙂 I'm excited, I'll try more ideas!
@@NoBoilerplate I'm honestly super duper happy you are exploring out of your comfort zone. The video you just shared is by far the most interesting and valuable technical video I have watched ever.
I love this! This is definitely going on my bookmarks. My last company used SAFe, and I completely related to the “spending more time in meetings than actually writing code” part. I HATE story estimation, and think it’s too arbitrary of a metric. I feel like a lot of the stories I estimated could have been done by the time I finished estimating them! The approach you suggested is what I’ve been thinking this whole time. Every team is different, and you can’t force a complete methodology and business practice on everyone. It needs to be *agile* and adaptable. However, taking a massive project and not breaking it down or tracking the pieces is overwhelming, so agile is certainly valuable, it’s just about analyzing it objectively, taking what works, and leaving what doesnt
Thank you! SAFe sounds just terrible!
My previous company did this and it drove me completely insane. You saw some improvement you could make to the code base real quick? Think again friend. You need a JIRA for that, you need to discuss the work to be done, it'll cause re-testing, you have automated tests? Well it might break something. Can't risk that, even though it's not in production yet...
Funnily enough, our JIRA's were terrible quality too. Vague boundaries for the work, we spent literally 4 hours a day "refining" tickets, that took realistically less time to implement than the hours we spent discussing them. Massive refining calls with the entire team for those 4 hours. It was an "I&P" sprint, innovation and planning and it was 90% planning. One of their innovative ideas to make our JIRA tickets better? "mini" 3 amigos (this is in addition to the regular 3 amigos the ticket goes through). Before you pick up a ticket, have ANOTHER MEETING you MUST HAVE a dev, QA and a business person to begin the work. Because that 4 hour discussion wasn't enough.
One of our "senior" devs got so blocked on doing work for the project, he enjoyed working more on side-projects than the real project. Wouldn't even seek out and try to do the "real" work anymore.
It was such a disaster. But makes for a nice'ol horror story. It really makes you appreciate proper agile, tearing back all the nonsense, cutting the crap, having a team that speaks their mind etc. Makes a world of difference.
While I do agree with many of the points in this video, I have been in projects where this breaks down, and where meticulous planning up-front was imperative for the projects success.
Specifically, I would like to point out the "the cost of failure is nearly zero" statement. For example, when the thing you're developing is responsible for billing millions of customers correctly, there's really no room for error. Not planning at all, releasing a just-about-finished version, and hoping to get feedback from your customers is not an option. That's a great way to get sued and/or get the authorities involved, and the cost of that is huge. Similar issues when you have to make sure the thing you're developing follows any contractual or legal obligations, really.
Also, "It's the only thing that works" is definitely, provably not true. People were doing software development successfully long before Agile came around. Maybe just chose the best tool for the job, instead of claiming there's only one true way of doing things, eh?
I think we're talking at cross-purposes, let me clarify my statements in the video:
1. The cost of failure is nearly zero is true in an iterative approach, but false in waterfall. If you show your user what you are doing every week, instead of after 6 months, it doesn't really matter if they don't like it in the first week.
2. The folks that wrote the agile manifesto didn't really invent anything, they just documented what high-performing teams were already doing.
I didn't mention it in the video, but the secret here is that "agile" is just the scientific method: Doing what provably works, not doing what doesn't work.
So it's no wonder people everywhere were basically doing the same thing!
As a former agile coach I worked with and consulted many teams and individuals. You my good sir get a lot right, and it bugs to hear it, even though I preach it almost the exact same way.
I was organizing internal "scrum basics" trainings and also conducted trainings in other companies for years and I always put a lot of emphasis on the theoretical side of Scrum and WHY it was created and WHAT problem it originally should solve.
Scrum has nothing to do with estimations or velocity or user stories etc. All these things "parasited" their way into Scrum, making it de facto bad. No one today knows what a user story actually is, but it is such a common buzzword, that everyone needs to use it, or they are "doing a bad job"...
That being said, you made a couple of statements to which I don't fully agree:
* As per Scrum guide, Scrum meetings are not ceremonies, but events, and if your plannings, reviews and retros have no deep significance there is clearly something wrong with the implementation
* Sprints are no framework for management, it is a frame to give the team a structured way of tackling "problems" (= making the product better), the frame consists of: understanding the problems and find a way to solve it (planning/refinement), implement it and keep each other up2date on the progress (Sprint and daily), review the work done on a product level (review) and review the work done on a interaction-level (retro)
** This can be seen by the fact that in daily only the team members are allowed to talk. It is NO status meeting, this is a meeting for the team to check which member needs help to do a good job.
* Just build something and get your customers feedback is easy to say, but so hard to actually accomplish. Sprints are a really good start to do it. If the team is mature enough in handling this kind of process in a quicker timeframe, do it. But hear me out: It is beyond tough to do.
As said, there are some excellent points in this video and it really bugs me that Scrum is being pushed into this management frame. Scrum is a product development framework. Estimations, velocity and burndown charts may be practices that many consider "part of scrum", but - oh boy - this just shows how little so many management people have understood in creating a good product today.
A testimony from an ex- High Priest of the Sacred Bureaucratic Cult
You're one of those people who talk fast enough that I don't have to put on 1.8x speed to listen. Truly, No Boilerplate.
The first version I recorded was compressed into 6 minutes if you can believe it. Folks on my discord were like S L O W D O W N and they were right!
1.8x?
@@Flackon Funny story, I actually do my first edit of my recorded scripts at 1.5x.
Second pass is at normal speed, last pass is to sync up the video.
And then there is fireship always rushing through his videos like he has to run to the toilet 😂
I watch him at 2x. My attention span is kinda nonexistent at this point
"Working software over comprehensive documentation" is good sometimes, but a more consistently valuable goal is to have a good balance between maintainability and immediate progress. It's the multi-armed bandit problem: "a fixed limited set of resources must be allocated between competing (alternative) choices in a way that maximizes their expected gain, when each choice's properties are only partially known at the time of allocation, and may become better understood as time passes or by allocating resources to the choice." (Wikipedia) However, I think agile forgoes this conclusion because of the role us devs often find ourselves in. The customer is always right, and if they requested something, they will get it. If the product they recieve makes no sense long-term, that's on them. They don't understand the code (they may not even have it), so at a certain point, if they want features, they will need to wait for the necessary refactoring. If the people who wrote the code are having a hard time maintaining /adding to it, then good luck finding a replacement who can do it faster.
Totally agreed, the manifesto authors knew that "working software" is "maintainable software".
I would like to say that LEAN manufacturing is the best parallel to agile software development. The Goal and The Phoenix Project are fantastic books, and they really focus on creating simple solutions for local problems. General, clear goals for software management does not really exist. I will try to make a pitch:
1. Increase throughput of releases which customers want
2. Decrease cost of features and cost of errors
3. Reduce WIP and dead code (this does not mean "do not write code", but instead, "do not leave features unfinished", and "remove code from production that does not do anything")
I tried to replace throughput with lead-times of testable releases, but it just does not seem to make enough sense. If these are the goals, then the goal of any software development organization should be to "Increase throughput of features while decreasing cost of each deliverable during its lifetime while reducing unfinished features and unused code", and agile should be the method for striving towards that goal.
Several years ago, I found a decent metaphor for explaining software development to non-technical managers: it's not an assembly line, it's creative writing.
No, seriously. Sometimes, our tickets are just correcting a typo, or a mis-ordered page. But most of the meat of our work is adding/removing/modifying entire chapters, or storylines, all while maintaining story cohesion and continuity. Now imagine that it's an entire series of novels, and you have multiple authors making large changes to the same book at once!
I have still found plenty of terrible managers and companies that couldn't be convinced to give a rip, but some are willing to process that, and realize what programmers are expected to do
Steve, you've hit the nail on the head: We're not factory workers, we're artists.
Brilliant comparison.
With more than 40 years of professional experience, I totally agree.
Assembly line workers are bored and tired, artists are excited!
The problem with Agile is the fact that they gave it a name, agile is supposed to be an adjective, not a noun.
I like this explaination
It's not what you do, it's how you do it
Variety from no boilerplate. I love this. Keep this up
I've got HUGE plans. Next video is back to a Rust one, just in case, but I'm going to branch out in 2023! XD
@@NoBoilerplate you aspired me to provide helpful content for other people (mostly narrow targeted tho). Great to see you grow. Maybe I will start my own channel when I finish my 20th meeting about changing api routes that we forgot to change in previous sprints. Frontend devs are also there btw)
Great video, continue confidently)
@@lukivan8 Fantastic, share it with me when you're published!
@@NoBoilerplate Will make English subtitles just for u
@@lukivan8 You're very kind! I bet the auto-generated ones will be 99% right ;-)
My scripts are here if that makes your job easier github.com/0atman/noboilerplate/tree/main/scripts
Straight to the point, no bs, just pure knowledge. I love your work! ❤
Thank you!
Great video Tristram! ❤
Having recently worked for a FinTech client that had a "Scrum of Scrums" in a JIRA Monster and hired _expensive_ "Agile Coaches" (people who don't _remember_ the last time they wrote any code, or worse don't know _how_ to code ...) to implement SAFe across the org, we _wish_ this video had existed and we could have shared it ... Thanks! 🙏
Yikes!
@@NoBoilerplate Yeah ...
imaging spending **60+%** of your work week in meetings ... 😢
Try to explain to non-technical managers that meetings is not where the actual _work_ gets done.
Totally Agree that "Agile is the only thing that works".
Sadly, most people "practicing" Agile aren't engineers.
Most people don't value the Engineer's time
because they aren't _paying_ for it out of their own pockets ...
Wasting an Engineer's time in endless meetings is _horrible_.
Anyway, thanks again for making this video. ❤
Incredible work. You've made extremely valuable content from the start, and I look forward to seeing what's to come.
Thank you so much Chandler, this was a bit of a risk for me, so it's great to hear :-)
The key is to find the balance according to your team and your product. The solution is never black or white. Methodologies run on agile by itself where you can iterate in order to have the best working methodology for you.
I agree with estimations, and the moral duty that if it's simple no need to plan it.
We use estimations for stakeholders and for us to gauge relative difficulty. If this is a 3, and the next one takes significantly more work it's a 5
. If the next one has the same amount of work, but it involves other teams, other stakeholders, we bump it up. I mean these are heuristics more than anything. I don't care how management uses them.
I value processes a lot. Should I spend all day writing to people in the slack channel reporting bugs on the website? Or should I have a workflow for them, to open a ticket, mark it as urgent or not, we pick it up, they can folllow process, they must fill in all fields to describe the bug.
Retro if used properly can be used to get honest feedback, bring improvements and the team together, if it's not hijacked by someone else wasting time talking about a task.
Who makes the tasks in agile?
What are the tasks entirely based upon?
Without the daily standup, how do you track the completion of the project?
The elephant in the room is that we need to change the way we work. I believe the creators of the Agile Manifesto aren't the first folks to come to the conclusion that we can do better. They called it Agile, but it's really just "stop wasting my time and let me get something done". There are a lot of folks that are working and don't understand what being a professional is all about. Our (in the US) educational system doesn't teach us how to think independently, it teaches us to follow directions. I find the most frustrated developers are those who do think independently and are not given the freedom to act on what they believe is the right thing to do.
The various frameworks are there to help. You take what works and discard the rest. Companies implement teams but don't understand the purpose behind teams. The majority of companies are still working in a top-down hierarchical mindset. "I'm the boss, do what I say". People new to the workforce don't understand any other way and are trained to behave the same way, so as they move up, the next wave gets the same treatment. All with positive intent but terrible results.
If you are a young developer/engineer, etc. you should know the Agile Manifesto. It was written by someone just like you, just after 25-30 years of work experience. Don't tell your Scrum Masters that Agile sucks, show them how Agile works. Build software, demo it to stakeholders, get feedback and iterate. Work as a team towards a common goal (not everybody working on something different) and get to know the people you work with every day. In my opinion, as a team, you should want to meet every day to understand what your plan is for the day and identify any impediments to your progress. Sprint review, sprint retrospective, backlog refinement - these are all things you should want to do and if you do them, the time is inconsequential. Why wait for a day or time to show your new working software off? Do it as soon as it's ready. If you identify a better way to do something, why wait for 2 weeks to talk about it? You should always be discussing the next things you'll need to take on. You'll need to do these things to get feedback and get better. Scrum gives you the framework, but what people rarely talk about is the adaptability. Take what works, discard the rest.
When it comes to estimates, don't think of it as a prediction as much as a safety warning. You should think in terms of small pieces of work you can create and test frequently so you can get customer feedback. Estimation is an exercise you can use to consider what will be required to develop a piece of working software. The sooner you can show it off and get feedback, the sooner you get confirmation that the direction you are going in is the right one. The longer you spend before getting feedback, the harder it will be to change direction.
Stop fighting Agile. Understand it and fight for what it really represents. You have a retro? Talk about what is really on your mind? What is NOT working and what do you want to change that will allow you to deliver working software quickly? Got a meeting that you don't want to attend? Is there an agenda? Do you KNOW how you are supposed to contribute? If not, can you decline? Are you empowered? If so, decline. If you get pushback, then you can discuss what empowerment really means. Are you assigned work or do you take work? Are you trying to get better? What would help you improve your skillset? Be an active participant in making you and your team better. Be curious and ask questions.
Finally, there are plenty of metrics for Agile and measuring what a team produces. But are you able to easily show how often you deploy to production AND what you deployed to production? The majority of metrics are really for the use of the team to understand if they are improving. The only metric that should matter to management is are you delivering valuable working software on a regular basis (are the stakeholders/customers happy?).
Really great take, thank you.
"The only metric that should matter to management is are you delivering valuable working software on a regular basis (are the stakeholders/customers happy?)." -- This is 100 percent how it should be.
Unfortunately, most managers come from a PM background and are addicted to charts. If they cant have their (gag) Gantt charts, then they want to see those burn down charts. If these people didnt exist we wouldnt need Scrum. XP would have been just fine. In my opinion, Agile was created to undo the mess that PMI certs have made. Only to have PMs transition to Scrum Masters and Managers and do the same thing they did before with bastardized agile terms thrown on top.
@@donparkison4617 IMO, Agile was created to get away from the manufacturing mindset. A group of people who didn't need to be told what to do got together and came up with a set of values & principles that anyone could follow which would just allow people to get the important work done. That was followed by frameworks because management didn't understand just values & principles. Then it became profitable to teach people and certify people and... well, you know where we are.
I agree that Agile shouldn't be a thing. It should just be the way we work. If delivering value (and the most important value) early and often, not burning out your people or treating them poorly is important, just do it. You don't need a framework to make that happen.
@@dwmichaels Agree completely.
Nice switch up of content! Would love to see some Obsidian content from you soon :)
On the topic of agile: our team decided to change the approach from a more scrum oriented version too, we still have some meetings but are a lot more chill about doing meetings if we would rather focus on coding. Your point on the story points has piqued my interest, I might bring that up, because I really don't see much of an advantage in the numbers too, but TFB and NFC are good to mention on a user story!
Yeah, that was new to me too. Basically it's "yes this is a story" "too big" "more info needed". I love it.
One of the most interesting video i've ever seen. I've always hated SCRUM, and had become resigned to the (mis)idea that SCRUM = Agile, this video literally changed my mindset, thank you!
oh my pleasure! It's a wild industry we're in, right?
Well to be honest a large part of scrum comes directly from the agile principles. Standup and retros are specifically mentioned in agile principles.
@@BigCarso which agile principles? agilemanifesto.org
Elephant in the room no one addresses: what happens when the developers that were working in the project quit and there is no documentation and the code is a mess. Good luck being the one that has to handle that
ouch!
Is pretty obvious and happens all the time because approximate time of a developer in a company is 20 to 24months.
Blame Agile for being anti documentation, now teams need more meetings to verbally explain the same all over again to the new hires.
That’s always been the Achilles Heel of “purest” Agile development. “Let’s skip the func spec because Agile Manifesto!” Developer(s) split and there goes the project deadline with them… because client projects tend to come with project scopes and project deadlines - something else that doesn’t seem to have been considered in this sort of “it takes as long as takes” approach to project management.
@@BigheadGenius : Every coin has two sides- the spec needs to be met within the deadline, but sometimes the deadline doesn't allow enough time to meet the spec.
"the code is the documentation"
I agree at some companies Agile only got acceptance when it became waterfall by a different name. I think of Agile as a way for a team to find a way to work efficiently that suits them best. There's also a huge range of types of software that can effect the process of building software, e.g. mission critical, highly secure, massive scale, regulated / audited, entertainment etc.
I used to sit though 8 to 9 hour long planning sessions every 2nd Monday with the entire dev team and the entire leadership team. We produced absolutely useless software that none of our customers bought. Company collapsed. We all got fired. I have refused to do Scrum or "Agile-ish" ever since.
I'm sad you had this experience, I think we've all had some experience like this (maybe not the company failing every time).
Faith in scrum in defiance of evidence is the insanity in many places.
If you hear people calling something agile that doesn't make sense with the manifesto, call it out, they're praying, not planning.
Funny thing is you as dev get the fingers pointed at you because of low productivity and poor performance. Get that on your stigma and you are dead.
Well no, I've had the opposite experience. Scrum has been the best process I've worked with.
@@errrzarrr That isn't part of agile or scrum. That's just managers being dicks
I love this, thank you! I've stumbled into becoming a programmer using no-code tools and now I'm building software for clients. Since building software was a hobby and the no-code space is tiny and somewhat disconnected/ostracised from CS circles I have found it hard to understand how to take an idea from a client and deliver. Estimation and over planning is truly a killer. Thanks again this helped me think a lot clearer about all this.
The most favourite and absolutely correct: just deliver a value.
The way I like to talk about it is that in most industries, the manufacturing of the product dominates the cost. So you need your plan to be right before you manufacture. In software, the actual manufacturing step is "hitting the compile button". It's so cheap we can't even value it properly. All that code you write *is the design* of the product. It's the blueprint, if you will. So, like almost everything else, we put a lot of effort into "getting the design right". But for software, because manufacturing is basically zero cost, it's far better to build it and test it with real customers than to iterate on design in the absence of a build (what traditional engineering does).
The interesting upshot is that as simulation gets better and better, you see Agile working for more traditional engineering. Test the simulation, in actual use cases, and iterate with similar practices to Agile. Refine the design in a world where "manufacturing" is cheap.
This is a really interesting way of looking at it, thank you!
Developing software equates to drawing the blueprint, not building the house. A design phase before building any software is like a design phase before drawing any blueprints.
The construction phase for software is compilation, it’s very cheap, writing the code is the design phase.
Things tend to break in the middle. I’ve had managers that are process trolls and jira cult leaders. Surprisingly their projects turnout like dog💩. Micro managing knowledge workers is a great way to lose good knowledge workers.
Working software is #1, yes absolutely. Supportable, stable software is the second most important metric. And because there's almost always a phase 2 to any well built software, HOW it is written is very often important as well. As in, cleanly designed code written with an understanding that it will likely need to be extended handle additional use-cases. This is where product managers can make or break a project. If the devs go into it with an expectation that their current requirements are the only requirements, they will bake that assumption into the design. This can make phase 2 dramatically more difficult (and take a lot longer), as it may well require rewriting big chunks of phase 1 in order to accommodate the expanded requirements.
Couldn't agree more, maintainable, well-documented software is working software
I was surprised to come across a video about project management on Your channel instead of Rust but I've enjoyed it a lot. I'm looking forward to more videos about IT as a whole.
I'll pay more attention to how I spend my time at work. I'd rather spend it on developing software and developing my skills than wasting it.
What I'll try using immediately is the idea you suggested in the comments. I'll try bootstrapping a new task by starting off with pair programming for the first 10-20 minutes and then let the assignee finish the task themselfs. As much as I'm willing to belive in the effectiveness of pair programming, it tires me too much to be forced to sit and code in a fixed time frame.
pairing is REALLY tiring, you gotta take it slow - I'm glad you saw that comment, perhaps I'll talk about my suggestions in a future video
Other specific comments already, but wanted to raise bits I don't fully agree with and see what others thought.
Sprint poker: If estimates show no consensus amongst developers, it's always worth asking the outliers why they gave those numbers. Can often uncover something the others had not thought about, or had and have a way to overcome, so reduces risk and increases understanding.
User stories: Quick meetings done right us worked for us. Forces the business to realise they have not though something through enough (business version of rubber ducking lol). Sometimes they remove from sprint, or get the answers that were missing.
It's a nice story, but my experience is that outliers are overwhelmingly people who 1. didn't understand the work, 2. won't be doing the work, 3. Didn't care to ask for explanation before the poker draw.
The value in explaining it to them is marginal, and feels like a waste of time to the other people in the meeting, who just expressed unanimity in their estimation.
I really want to know, what do the vast majority of "project managers" actually bring to a project ?
Like, the vast majority don't even have a technical background.
I've worked with very few PMs who understood that software is DIFFERENT. The few that did followed the Manifesto's spirit, and had a very hands-off approach.
I haven't seen such a good channel in such a long time. Just wanted to leave this here. Keep it up. Your positive impact on me has been insane.
Thank you so much!
I would add that, while "working software" is important, working software that doesn't add value (eg, solve a problem, meet a need) is by definition valueless. You're not done when you release working software, you're done when the value exists (eg, problem is gone, need is met). Working software is your current best guess at what might provide that value, but it's not the point. It's merely a measurable, doable means to that end. Put another way, working software is a lead metric; value added is a lag metric. Value is what matters, but you can't directly add value: you can only directly make software. So make software. But if the indirect but actually-important value doesn't result, go figure out what software to make (or rework or some other non-software solution) until it does.
Scrum is a great tool if is applied properly and in the right context.
I’m a SM in for a team of 11, working with other 8 teams on a large scale solution for the private operations of one of the biggest banks in the world. Now, think about the amount of stakeholders, strategic projects, impact of every change,the amount of dependencies and so on.
In this environment, Scrum does for us exactly the opposite of what you said: it allows me to shield the team, reduce the noise and keep the team focused on what it has to be done.
I've also been in teams where scrum has worked well - the thesis in this video is that scrum is not a one-size-fits-all method, and I suspect the majority of teams using scrum would be better suited with something else
What an excellent and clear summary.
You cut through so much noise and bullshit on this topic. Well done.
Saving this to show managers
I agree that the overhead and ceremonies are an excessive veneer of corporate control. Nevertheless, those come from two fundamental realities: 1) businesses need to finance R&D and ensure return on investment 2) customers have timelines for delivery, so promised delivery dates are important for customer service
So the "you're doing agile wrong" says to me "I'm an artist why don't people pay me for what I want to make". There's a bit of entitlement to the sentiment.
Are there ways to bridge this? Yes, and it involves devs and product owners spending more time with customers and understanding what they want, and why they want it, and why they want it when... straight out of the horse's mouth. The dev team needs to be part of the feature bidding process.
We completely agree on the best way to do it right: Early customer feedback, straight from the horse's mouth. But estimating how long that best way will take is VERY difficult.
Ask a poet how many poems they can write in a year, they will say "I literally cannot tell you"
Ask a developer how many features they can write in a year, they will say "I literally cannot tell you".
I'm not being entitled, it's just how it works, and anyone who tells you otherwise has something to sell you.
@@NoBoilerplate well my finance office will ask "how long will it take to build the feature or meet the requirement", and the customer will ask "how long will it take for you to keep your promises"....
....a poet can shrug and say that "I literally cannot tell you" but then both the board and the customer say "well then I literally cannot pay you."
... and that's before CyberSec run a linter over the code and CICD pipeline and insist that it has to be fortified before it's suitable for Production deployment.
@@cassiuslives4807 I don't doubt there are ways to give estimates to those people, both time and money. The agile manifesto does not say anything about that, and cramming in estimation into it causes a great deal of problems.
This sums up the problems with the way we use agile really well.
This might be the most succinct and illuminating explanation of the issues on this topic. Which is even more amazing considering the portion of time devoted to crediting another person!
Thank you so much! Ken from CTTM and I started at about the same time, and so we connected and did this little shout-out swap! It's such a nice community!
Scrum is a terrible trap to end up in for most organisations. The issue isn't scrum directly. But rather that its not meant to be implemented organisation wide in a fixed manner. Agile isn't a process, its a methodology to approaching software development in a dynamic and flexible way.
The issue is, Scrum takes the inherently reactive approach of agile and applies a very traditional pre-emptive narrative to it. You can't plan your way out of chaos. You need to have a goal in mind and drive towards it in as small steps as possible.
I'm a huge fan of XP practices and applying periodic goals to a kanban style of working. The way I see it, you need to have three things to be effective in an agile enviornment:
1. an overarching goal for the next 3-6 months (Some idea, some technical principle, some project vision)
2. a rough plan for the next couple of weeks (some chunk of work, like implement caching, redo front end rendering etc)
3. willingness to scrap almost everything
Without that, you have nothing. You need goals, and targets, but you need to accept failure is part of the process. You implement idea x, move on, if X is no longer fit for purpose you redo it..
SO, you have a goal -- some new project, you have a very rough idea of what it needs to look like, you start throwing things together, POC's and spikes etc. just do it quick and dirty. Then you take look at what works, whats broken, whats horrible to look at, work with etc, Then you two together a rough idea for what needs to be replaced or redone. you have three categories:
1. Now
2. Next
3. later
You don't score, you don't estimate, you say, this is now, this is next, this is later, If management need estimates, you say now = small, next = medium, later = large. You don't do anything too large, you look at work, see if you can implement it, break it up if not, But that's it.
every time you finish a few tasks you bring in the next piece of work. Heck, you can make it so you don't pick up more work until the entire team is finished if you want to avoid true kanban,. but you should just try and implement stuff.
Jira is a brilliant and a terrible tool devs. Its great for keeping track of what you're doing, but its often a anchor. Jira should be used simple to keep track of whats being worked on. Nothing more. Maybe for AC's or bug reporting. But that's it.
Test everything. but avoid massive UAT servers and test environments, Try and avoid regression tests and integration tests,. You want to keep testing light, fast and effective.
Next time someone mentioned Scrum certs or agile coaches, run away. push back as hard as possible,. you don't need an agile coach, you need to just start being more active and more deliberate. pragmatism is the key here. Oh, this solution works, but will likely break at 10x the projected load, unless you know you'll ever hit that, just implement it. move on, refactor and replace later.
makes sense, the framers of the Manifesto came from the XP crowd, and all hate scrum!
@@NoBoilerplate the wild thing is, it didn’t need to be like this. Developers have done this to ourselves. We’ve pushed and pushed from agile and Scrum constantly for decades trying to move away from waterfall and have allowed agile and scrum to become synonymous with each other. We’ve allowed for our goals to be more autonomous and efficient and reactive to be co-opted by middle management and project managers. And we can’t blame them.
The only real solution is to break down the barriers between product and engineering and really make it clear the processes needed to deliver a solution.
Hilariously, the most effective and efficient team I ever worked with was a full on waterfall team. It’s wild to think, but they were genius. They managed their roadmaps like series of micro waterfalls and planned everything to the limit. But in tiny tiny chunks of 3 weeks. It was wild.
But, I don’t think that approach would work in most cases.
I like your style!
Informative and good as ever. One little suggestion if I may: why don't you add the numbering to the video title later on. I think it'd be better for the algorithm if people didn't think each video was part of a series (which they kind of aren't since they have self contained topics)
OOH thank you, gonna remove that now
@@NoBoilerplate Thank YOU for the quality content, that's what makes me wish for this channel to grow big
Big teams can respond to change fast, in my case we're 2 devs and we should have planned from the start, but that did not depend on me and we're way overdue since changes take long
I follow your very useful videos and I also follow Allen and Dave and Martin. I do dislike Scrum, Ceremonial Agile, SAFe (ugh!), and more than anything Jira and certifications.
There is one way to learn and do Agile: Do agile! And there is one way to learn it (besides doing it): do it with people who have done it before and successfully if you are lucky to be in such a team.
BUT, one thing I guess we overlook is the FORMAT. In the long term, Format is more important than Content! That is why religions with rigid ceremonies last and liberal approaches to religion ceremonies die. In software design, this is projected in Conway Law. Maybe, the only design law in software that I am aware of.
It is important to have simple but (kind of) rigid formats, processes, chart, team formation, communications, version control, release cycles, CI/CD in order to have a successful product for a very long time.
Thank you for putting what I've been feeling for the past couple months into such clear language. Great video!
You're so welcome!
Most of the time when someone blames scrum or other frameworks, it's not the fault of the framework, but the companies/managers.
for example: having to much meetings when spending one to two hours a day refineing and estimating is not part of agile. in scrum it is the responsibility of the product owner to refine, that developers can work efficiently. estimation is not required. but most people think it is part of scrum and blame it for, then in fact it is not.
you don't need to do that if this is not fitting for you.
working more agile should never be a overhead. it should give you more. more feedack. more transparency, clearer storries, and than: more (quality) time to code and not spending an hour figuring out what a story with only a title should mean, and doing it twice because you misjudged.
keep focus what you realy need to do, to be agile, and stop blaming scrum for companie specific decisions
7:30 Please correct me, if I'm wrong: Does that mean, that you should never write comprehensive documentation, because that time could be better spent writing more software?
Sorry, I see I wasn't clear, I should put this in the ERRATA comment:
I love code documentation, api docs, etc what I don't like is process documentation, overhead documentation, all the stuff that literally doesn't matter if you don't do it.
I do agree with most of the points on this video, but I can’t seem to understand the “do not plan tasks and don’t estimate them”
I am a software engineer that wants to not only understand what I’m gonna be working for how long, but most importantly when can I expect something else to be done for me to continue it.
And I don’t believe pair programming or always asking is the answer here 😅
To be clear, I only said don't estimate. When planning takes less time than doing the task, there could be value for your team, for SURE. It's when planning takes longer than the task that I get frustrated!
Estimates are worthless if you do nothing with the estimates. Just prioritize.
I'd very much appreciate your perspective on how to address nonfunctional requirements in the context of agile (or whatever) development. I'm a security guy, and it's really hard to sell customers, or even other engineers, on a "feature" that just consists of "stuff not breaking." That's applicable to security in particular, but also in general to reliability concerns and architecture work, as well as handling technical debt.
Usually the customer can't give useful feedback (because it works fine if they're not pushing to prod, and ideally all they see is things not breaking), management doesn't understand why it can't just be handled in the same style as acceptance criteria, and engineers don't want anyone bloating their tickets' AC with things they can't directly test for.
I understand, I worked for a year and a half in one of the uk government's cybersecurity departments! You must have buy-in from the top. Ideally before the breach, but when it happens, THEN you make sure you get it.
Thanks for the shoutout, and fantastic video!!! Agile can definitely be a footgun in the wrong hands.
My pleasure, your videos are so great, Ken! Thank you for making them :-)
I’d absolutely love to roll back the cruft and plan less, it certainly sounds like the way. The main problem (in public sector anyway) is the PM who needs to report the project progress to their bosses. Whilst there’s many ways to do this, they almost always fall back on sprint burn down, which requires all the other planning junk to work, so it gets done as a necessity prerequisite. Still sucks though.
I worked in the uk's Government Digital Service for 4 years, finishing only recently, so I feel that!
My advice would be for the PM to focus on larger features, demoable outcomes, rather than tickets. %age through a certain releasable epic, perhaps.
@@NoBoilerplate agree! Show progress through showcases/demos, whatever they’re called it’s not important. I will continue to fight the good fight, currently trying to convince the org to not do ‘backlog grooming’ on day 2 of the current sprint…..
Fully agreed that too much process and ceremony can be detrimental to progress. But on the other hand, in my humble experience, certain tools, agreed upon ways of working, documentation, feedback from both customers and from peers and some ways of making sure devs and dev teams aren't working on duplicated, competing stuff or some stuff that should be cared about goes without caring are a must. So is connecting all that jazz to the other parts of the organizaion. On the other hand I'm all for competing prototypes, but we should have everyone commit to the one with most long-term merit and coherence for the overall solution.
Too often I feel like "being agile" is used as an excuse for not doing any planning and not coordinating work with the company as a whole and all sorts of unmaintainable gung-ho short term hacks that screw you over in the long run. I feel that there's a lot of good stuff built into Scrum and most of the events seem to have a valid purpose. I would be very interested experiencing a reasonable implementation. I have never witnessed Scrum in action myself.
'being agile' does indeed tend to cover a multitude of sins - I hope you've seen I'm arguging for an evidence-based approach. If scrum works for your team, great! If a heavyweight process works, great. It has to WORK for you - there's no one-size-fits-all, but there doesn't have to be.
@@NoBoilerplate Thx for the reply! :) Working as a mixed IT admin and software developer for a programming house that also does electronics and device manufacturing and very much doesn't forcibly restrict your role inside one particular box sure puts a whole lot of spin on thinking about these matters and grants an unbearably wide perspective on many types of issues and viewpoints. I try to think about it all too much for my own good, but hey, being holistic is a good thing right? And it sure doesn't get boring. Now if only I could grasp all of it or at least the most significant parts from all over the biz and make some concrete good come out of all the pondering and wondering :D Or die trying. Work in progress.
I love the message, and couldn't agree more about agile. Management often look at scrum and safe as this prescriptive cure all and quickly lose most of the value out of their developers by bogging them down. I do have a nitpick with the idea of not estimating and by relation; sprint planning. In my experience, there is great value in communicating with the team on what everyone is planning to build, and the outcomes they hope to achieve. This helps limit waste if we are actually iterating fast. Most of all, I value the information the team learns together at the end during a retrospective. As for heavy tool usage, large companies in the US have a lot of conflict actually working this way, especially public ones. There are many metrics that have to be tracked for audit and tax purposes, and the overhead caused by tools are used to (hopefully) automate that tracking. Not to mention the need to track and plan for large releases across the enterprise's projects.
love planning, hate estimation!
Regarding the documentation, I agree that good code is self documenting. BUT as soon as you leave pure development and enter the realm of DevOps and need to deal with Operations then documentation is a must. Especially if you need to do 24/7 and the skill level in the team varies.
Good documentation is part of a good system, absolutely.
I have more than a decade of professional experience and I'm yet to work for a company that is not doing "Agile" the way every developer hates it (bazillion of meetings, estimations, poker planning, 2 weeks sprint, etc.). It's gotten to the point where when I see "agile" in a job description, I just close the tab and forget about that company. I'm 36 and I've never worked in a truly agile company. Depressing.
Hey! We're the same age! But yeah, it's SO rare. I worked in a Thoughtworks-run company, and it was KINDOF good. Pairing, and lightweight scrum. But the CTO still screamed "WHEN ARE WE GOING TO MAKE THE PRODUCT" half way through another 2h meeting once. That was funny.
This is without doubt one of the best things about agile I’ve heard in a while! Thanks for putting the word out there!, will look at the source for the inspiration too!
My pleasure!
I think this is a model that makes sense in the context of a piece of software being built collaboratively with a customer as a service, which is frequent in spaces like web development, but starts seeing some major friction in software written as product (eg video games). Software as a product needs to be able to sell itself, not just meet needs. It can never meet needs if it doesn't get bought. We can't go back and forth with our customers until we have customers. We do what we can to estimate, and simulate, customer feedback. But at the end of the day we have millions of customers, we'll only ever hear from a vanishing fraction of them, and mostly after we've already finished and wrapped a product. And in games especially the meaning of "working" has significant logistical overhead to even define and measure. What is working code when the only measure of working is "fun" that has to fit into a multi hour, sometimes multi month consumer context?
A common problem - I believe the common solution is using a "client proxy". If you can't get the client, then get a simularcrum - product owners, or game lead designers or testers etc. I totally agree that it's a difficult problem, and I'm not suggesting any other solution than to start with the manifesto and build up from there.
A game dev studio shouldn't just use scrum and hope!
Nailed it! No scrum, build/deliver direct to end-user - great, but in my company, engineers are shielded from the end-user by a layer of technical management. It makes it this much harder to penetrate this bubble.
So counter-productive!
F**king hell I watched this video 4 times in the last three days and I cannot express how hard this video hits working for a company that is a contractor for a company that wants us to work in a SaFe environment. This summarizes all issues that we currently face and the reasons why this is not working
Thank you!
My pleasure, I'm sorry I don't have many answers for you!
Another good quality video from No Boilerplate, I love the fast-paced data dense videos no matter the content of it. I believe I watched another video from another channel which shouted you out too for this, just nice to see your way of doing things is getting known.
dumb me... its code to the moon's video if I remember correctly.
Yeah! I contacted Ken and we did a cross-promo, it was very friendly :-)
Thank you so much!
Here is the agile interpretation I was thinking the same thing about. You explained it much better than me.😅
In my previous org I used to spent more time in filling data on our scrum project management tool Targetprocess then actual development.
Terrible!
Ah, the proverbial _People over processes_
Re: the house building comparison, I think the reason a traditional plan-meticulously-and-them-build approach doesn't work well in software is that software development *is* mostly planning to begin with. Meticulously planning software ahead of time can be like making plans to make plans. That's not to say there's no place for planning in software though; for complicated systems having a plan for the general architecture of the system before you start implementing is probably always a good idea.
Yeah, it's like how some writers say they write to plan, not plan to write. The action of doing IS the planning.
Most meetings I put together as an engineer, people walk out commenting that it was productive and they got something out of it. Most meetings the scum leaders put together is met with exasperation and thought to be a waste of time.
Kanban > Scrum. Where does Design fit in to your thoughts on Agile? Thanks for this video!
Designs are good, working software is better, so I'm down to design, as long as it doesn't slow down development overall
This occurred to me for the first time while pausing to reread the manifesto bits at 1:15. "Individuals and interactions over process and tools." Scrum (which isn't agile, I know) and how it has been implemented at past companies is almost exclusive process and tools.
Now you're thinking with portals!
I've been subscribed for a while but I just started *paying attention*. Outstanding content, I'm rebuilding my whole perspective tech stack.
I like this. I feel agile, or the perversion of it that companies today believe is agile, is something we need to have a sober discussion about. I feel it has become "tell teams to do X" and the core values have been forgotten. Just like you say, the teams are supposed to figure things out as they go so their solution fit in their eco system and with their knowlege and challanges.
With that said I do believe Scrum (which made a concious decision to move away from ceremonies to events) can faclititate successfull agile development when working with complex problems.
But Scrum is incomplete by design. It only "mandates" the core aspects that are needed for the feedback loop and continued learning to take place.
The problem is that several things not part of Scrum have become what many believe Scrum is. Burn down charts, story points, valocity... and on and on.
Sure, if they help your team in their work you can use them, but they are not mandated by Scrum... but sadly they often are by management. Which by itself is an indicator that the plot of the entire thing is lost to the organization.
OMG, you nailed this on every point. Thank you! There's no telling how many days of my life I've wasted in daily stand-ups listening to people try to make it seem like they were productive since the same time yesterday. The micro-managers just love it. And out of all those thousands of meetings, I would wager I've heard something useful in maybe five of them. To management, Agile is synonymous to Scrum, instead of Scrum being a subset. I would like to try Kanban, but no one seems to know what that is. And the Scrum process becomes the new religious dogma. You estimated more hours of work than remain in the sprint because something is taking longer than expected? Oh No! The burndown chart is now in the red! You better work late to fix that for the arbitrary sprint deadline so our retrospective charts look pretty! This shit has really ruined my love of a career in software development. I currently work in the defense sector. You can imagine how bureaucratic any process becomes in an industry that's tied so close to government, the epitome of inefficient "process". I can't wait to retire.
That sounds tough my friend. See if you can get into a smaller, younger company, and in the interview ask them how many hours of meetings they have in a week.
If they don't know, thank them for their time.
I've seen a couple of places do scrum and agile and what they've all failed to do is iterate. Developers work twice as fast and are 10 times more enthusiastic when they have a rough crappy prototype of the final product. If the choices are "A crap prototype in 2 days" or "A nearly finished product in 2 months", I guarentee the crap prototype will turn into the finished product in way less time.
Really good to see you promote "Code to the Moon".
There are some poor quality content creators who upload videos that cover nothing other than the Rust docs.
On the other hand, both of you upload really good content that resonates with me, as somebody who has been working as a software engineer for almost a decade. There are real, enterprise concerns being mentioned here.
I'm so pleased, thank you!
@@NoBoilerplate Yeah, I'm definitely going to check out CTTM. And I've really enjoyed your Rust videos as well!
I really like your videos, but this time I feel the need to write a comment
because my jimmies are a bit rustled.
First of all, I 100% agree that what's currently out there in the industry has
long stopped being (or never was) "Agile" in the original sense and instead is a
bullshit marketing term for management, making things worse than better. That
being said, i doubt that just following the Agile Manifesto is enough to lead us
out of the software development process jungle.
- The reason the Agile Manifesto has survived for as long as it has is because it
is not really actionable (and that's ok, its purpose is to outline the
fundamental values of agile work).
- Even for pure software projects, people struggle to translate the Manifesto and its
12 principles into actionable steps for the trenches of the software development industry.
Even the most fundamental question, "what is valuable?" is extremely hard to answer and
"involve customers" is only the beginning.
- Many software projects (I'd argue the vast majority) are entangled with domains that
have longer cycle times like certification, electronics, hardware etc.
requirements and constraints are coming from.
- I don't know what "working software" is. Is it when the customer is happy? Is technical
quality part of it? Maintainability?
I don't want to sound unfair because it's a 8 minute video which can't just solve a methodological
question of the past 40 years. I guess what I am trying to say is that we are still
far away from a methodology where we can say "do that and you'll get a good software product".
Thank you for your comment, good to chat - I totally agree, my video mostly points out what is currently not working, rather than provide answers.
The FIRST STEP is to realise that scrum/kanban/solid isn't the only way to do it - the way to do it is to start with your exact problem and domain, understand the agile principles, then work your way up from there.
As you say, if you're bound to long lead times or hardware or government policy, you will work your way up to something that builds those immutable foundations in.
But you'll never know if you don't start from the manifesto and work up! :-)
I’ve been programming to 32 years. You are 100% correct 👍
Thank you!
The pushback I frequently get is that we are singing external contracts with people who expect and thing by a date. We can't really get a 5% contract signed see how it goes and iterate with this people. How does one agile in that environment?
A great question, I don't know the answer to that, and the Agile Manifesto does not pretend to either. Agile is the fastest way to write correct software, but sadly, as I said in the video, it does not produce deadlines. We can only know that we are writing software as fast as humanly possible, to the customer's exact, and changing, specifications.
Fresh air, thank you!
Thoughts on Next.js 13 and Turbopack?
Thank you! Not tried them, any good?
@@NoBoilerplate Currently looking into this, should be really fast from a User point of view as they are moving more to server side rendering. If you get around to look into this, I would love to hear your thoughts, Thanks!
I was with you till the end "The user's definition of working software" is the thing that minimally does what they want. For which the blame when it doesn't do it excellently and securely will fall back on the developer. Seems like a raw deal.
"the blame when it doesn't do it excellently and securely" Sounds like the user DID have definitions of security, they just didn't articulate them. We as developers know that there are many implicit expectations of software, security being one. Part of the job is looking ahead at the things the user will eventually realise they need.
Should the project manager still help breaking down the tasks or just let the team make it works?
The project manager doesn't have the domain knowledge to do so, that's why one of the team wears the PM hat.
I'm struggling to see what the answer to the question you posed actually is.
At 4:32 you pose that what agile is bad at is answering the question "When will it be done?" and that the "People with the money want the answer to this question." This is completely true in my experience!
However, the solutions proposed are "Don't estimate" (5:12) and "No sprints" (6:34); you dig into why these could hold a team back (with which I largely agree) and discuss that we should "Get feedback from a customer as early as possible".
What I'm not hearing, at least not directly, is an answer to the question you posed. Yes, we can remove waste from processes by not estimating and by not having scrum ceremonies - but how do we tell someone how long a piece of work will take?
I'm by no means a scrum advocate and I'd happily do away with estimates / ceremonies to improve the effectiveness of the teams I work with, but I don't understand how this translates to satisfying the needs of customers who want to know when we can deliver something.
I'm sorry Adam, you're not confused, I indeed did NOT propose an answer to the "how long will a piece of work take" question.
In my experience, nothing answers that question reliably, so we invent processes that look good to management.
Exactly. Read the manifesto and don't use the the shorted version with only bullet points like "working software over comprehensive documentation" that are so easily misinterpreted wrong.
I stumbled upon a job description that included "agile daily *rituals*".
Still in shock
Pretty clear but I have to disagree regarding the documentation, at least the internal documentation.
- First the domain can be complexe and you cannot expect people to go through implementation detail to understand the complexity. As an example, AWS has some great lib with good documentation but some of the core concept need higher level documentation, containing illustrations and stuff.
Introducing new comers to a complexe problem through a code base is utopic.
- Second, the code base is the final iteration of the product. It does not contain the information related to the previous versions, why it evolved the way it is today. Having an internal documentation explaining the rational between the implementation of a feature is crucial, otherwise it will be lost and create endless debates.
I agree it’s a lot of time invested but IMO, it’s worth it at an extent.
Note regarding sizing: don’t be fool. The main purpose of sizing is for managers to compare developers’ velocity. However, it also helps to spot potential divergence regarding the complexity of a task, which sometimes reveals some unsuspected consequences of a feature.
In my experience the inaccuracy of bottom-up story points is so great (over 100%) that any statistics and trends are not to be trusted.
Junior Java Engineer here, I’d say that at a lower level i don’t have many meetings, in fact most is over messages until it gets to a discussion of more than two. Cant say i’ve had any unnecessary meetings… maybe it’s luck, or maybe i’m not senior enough to be considered worthy of them ahah
What would you suggest as a starting point for learning SCRUM?
scrum is nothing, wikipedia can teach you scrum:
"Scrum prescribes for teams to break work into goals to be completed within time-boxed iterations, called sprints. Each sprint is no longer than one month and commonly lasts two weeks. The scrum team assesses progress in time-boxed, stand-up meetings of up to 15 minutes, called daily scrums. At the end of the sprint, the team holds two further meetings: one sprint review to demonstrate the work for stakeholders and solicit feedback, and one internal sprint retrospective."
Learning what WORKS for software teams is very different.
The Manifesto works, but doesn't prescribe very much, and that is because it's very different team-by-team. Scrum might work for some teams, kanban might work for others.
I'm sorry that's not the answer you wanted, managing artists (which is what software developers are) can't possibly be the same in every team. But I do have a recommended reading list for you:
holub.com/reading/
Corporate Agile/Scrum has become a micro management system tbh.
agreed, capital A Agile is terrible. we can take it back, though!
The hardest part of software development is the struggle with capitalism. Your employer is attempting to maximize profit for leadership. You are trying to write good software and the two goals are often diametrically opposed. You have to be willing compromise a bit if you want a paycheck
I agree with a lot of your premise but not necessarily your prescription. Over my career I have fought and fought with people who do half assed scrum and use Jira and stand ups to micro manage developers. So really, the motivation of the leader of the dev team should be to protect the team from micro management and unrealistic expectations. If the motivation of the leader is to impress his/her bosses with cool metrics the whole thing is doomed. Scrum is just another stick to beat people with at that point.
So if the team lead / manager has the right motivation, how do they protect the team from PMs and C suite nobheads? Thats what velocity & capacity are for and you cant do those things without sprints or estimating. Here is another place where this often goes wrong. When managers (usually those PMs) insist on estimating in hours instead of story points, or even worse they talk in story points, but equate them to time boxes. When I see a team estimating in hours or time boxes (other than the sprint itself) and its obvious their process sucks. They are trying to make good burn down charts, not good software.
The only reason story points exist are to compute a velocity (average story points per sprint) in order to calculate capacity (Velocity adjusted for availability). And the reason capacity exist is to protect the team from overwork, micromanagement and an unsustainable pace being forced on them from on high. This is the team's capacity. That is all they can take on this iteration. And if you do it right, you leave room for refactoring, testing and innovation in process.
Here is another huge red flag. If you hear anyone wanting to 'increase team velocity' or compare teams against each other using velocity, then you have managers creating unsustainable pace. And what happens when we work at an unsustainable pace? Our code sucks, I.E. we have broken the cardinal rule by putting the process over the software. People being forced to work faster, inevitably introduce more errors into the code and innovate less.
I always say, never confuse the Artifacts of work for Actual work. BUT, you need some number of artifacts to show to the people paying the bills that working software is being delivered at a reasonable rate or to estimate when a certain number of important features will be delivered. But this isnt really for them, its for the team. Is so managers dont feel the need to dive in and get in the way by trying to 'get the project on track'. That is always a disaster. We all have lived it.
But after all that, if you have the choice to do True Agile, where story points, estimation, sprints and velocity dont exist because you dont have to report to people who have no understanding of how software is built, then great! Maybe you work for yourself or a cool startup that gets it. You enjoy a rare and wonderful place. But thats not the world most of us live in. The best we can do is create a shield around the team so they can do work in as close to an agile way as possible. That is what scrum is supposed to do. Give management enough information to not panic and to leave the team the F**k alone.
The problem with removing estimates is that it's impossible to provide a cost to build a product or a time frame to release a feature or patch.
Removing estimates is awesome if it's a team dealing with new verticals in an established company, where building a strong foundation is more important than quick delivery, but otherwise a nightmare for managing clients.
Also, in my experience, removing estimates and responsibilities does not mean better code and products. For bad developers, it just means the same quality taking twice as long.
It is the old case of good developers paying the price because of the bad ones.
I see what you mean - I'm not suggesting that there's NO place for cost estimation - but that the developers should spend only minimal time in meetings about it. Where does that leave estimation? Elsewhere, I think.
FALSE.
If your user stories are all roughly the same size then over time you should have plenty of data to confidently give an estimation within a standard deviation or two.
Majority of IT seems to be closer to plumbing and other construction related work nowadays: there’s a goal, the are limitations and some unexpected issues along the way, but for some reason IT folks consider that not having a plan, ETA and risk awareness is fine and clients should have no issues with this.
What you described assumes that you have a team of highly capable developers. In the corporate world you often don't have this and hence why you need guardrails.
Agile is great in certain circumstances. However, in some cases, building software IS like building a bridge or a house and detailed planing IS necessary.
But in the software industry we a fad followers. New framework, cool. New language, awesome. New management process, sure. And we do this without ever considering if these things make sense for the TYPE of project we're working on.
I'm not saying agile CAN'T scale up to building bridges, in fact I'm saying it absolutely can - I work in the UK's Government Digital Service - we use as lightweight processes as needed.
On billion/week payment processing systems, you better believe it's heavyweight with change-request etc, but when we needed to roll out the covid tracking app, we did that shit AGILE. www.gov.uk/service-manual/agile-delivery
(my opinions are my own, to be clear)
'Agile' is just responding to reality. Totally agreed that reality occasionally needs heavier weight processes. But it should be as light as possible.
Were being taught agile through scrum, where I'm studying CS, but I've often felt that it was impossible to estimate tasks that involve technology you haven't even learned. This has lead to us ditching most of the ceremonies of SCRUM, and instead focusing on getting work done. This however lead to another problem, where the less experienced members of a group end up stuck, confused and/or left behind, since they rely on a lot of the planning for certain tasks, in order to break down the given problem. So as a student I feel kinda stuck between these ideas.
Any ideas on how to handle such situations, and what is your opinion on agile development from a students/learners perspective?
Normalise task kick-offs. "Hey folks, I'm about to start task X, Could I have a few people to kick me off and get me going on it? Thanks!"
Pair programming
@@arthurderyckere8732 LOVE pairing. A core part of XP, which scrum ruined.
I wondered how schools were handling this, since agile wasn't really a thing when I was in school. Hell, we never covered anything about managing / planning large projects. It was always just one-off programming assignments. Actually thinking of my first real job after college, we basically did a simple "agile", it just wasn't called that. We'd have meetings when necessary to plan stuff and go to work. We'd have impromptu meetings whenever needed to clarify issues or ask for help. It was awesome.
@@rancidbeef582 Agile's basically just the scientific method. Hypothesis, experiment, theory or repeat.