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 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.
Corporate agile = several waterfalls happening simultaneously while not being able to find documentation divided in 50 pieces stored in 100 different places
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 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
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 🙂
@@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 ;-)
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.
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!!
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.
@@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.
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
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!
I build an OpenSource Profiler with one of my colleagues, and we had an extremely tight deadline. So we just puzzeld it together, figuring out what we needed on the fly. After we just managed to make it work before the deadline, I spend the last one and a half years to rewrite it as a sideproject, because now I knew what we actually wanted from the start.
In my experience, the third reimplementation of something is usually really good: one implementation to explore the concept (realizing your initial mistakes along the way), one implementation to build a decent version (realizing deeper defects along the way), one implementation to get really polished (avoiding e.g. most technical debt in the process).
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.
@@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
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!
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. ❤
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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
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.
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 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.
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 have found what I think is a misunderstanding to "iterate code fast". I've had software engineers developing a frontend app in days or weeks to show them to the stakeholder, just to receive a "thats not close to what we are looking for". Planning ahead is NOT against agile. Having a quick scratching in paper session of 30 minutes that can help you understand the needs of the client and use that scratch to iterate the first time faster is indeed making your code better. We should not only deliver code, but look for ways to iterate faster without sacrificing quality.
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.
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.
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 last job made me sit through a long-ass meeting every other day, and during the vast majority of days I had nothing to do. I either had to wait for my moron teammates or asshole management. This funniest part of this is that they PAID FOR MY AGILE CERT
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.
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.
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.
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.
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.
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
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 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.
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
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!
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…..
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.
Рік тому+1
Here is the agile interpretation I was thinking the same thing about. You explained it much better than me.😅
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!
Just wanted to let you know that you are my favorite tech-youtube channel and the only one that i would watch again and again, not because i dont understand, but because i love your voice and points... must have watched some of the rust videos like 5+ times. Keep on fighting the good fight and take this comment for the algorithm : )
That's fantastic news! I was a bit apprehensive about releasing this video, as it's outside my usual type, but everyone's so nice about it! Thank you :-) If you want to hear more of my voice, there's 10 seasons of Lost Terminal to enjoy, I'm so proud of it ua-cam.com/video/p3bDE9kszMc/v-deo.html
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 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.
You would not believe the depth of argument, over an hour, I had with using number story points or t-shirt sizes. The other developer likes numbers, specifically golden ratio numbers, with arguments of arithmetic purity. I like my stories small, medium and large. It's all estimation anyway, I'd rather convey the gut feeling rather than some analytical numbers detached form the human experience of actually developing software. He conveyed the want and necessity of managers to track progress and work from developers. The sizes don't do that. But if my boss is relying on these numbers to gauge progress then he is too detached from the project to be an effective manager.
I too try to argue for t-shirt sizes: S M L. I've been in teams that had a whole STORE of different sizes. 3XL I kid you not. I now am fully converted to 1, TFB, NFC!
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.
5:15 Unfortunately, that only works when everyone on the team is motivated to accomplish the goal. Once you have people who treat the job only as a source of income and do the minimum amount of work required to not get fired, this no longer works.
I wonder how you can start a project without a rough estimate and a business plan and when you ask a consult from a software company all you hear are jargon words like MVP, hourly price and number of sprints with no warranties on what will be delivered. I mean, Agile works when you are a hired coder with a wage but someone in some other office has to plan, needs estimates, writes contracts and SLA. Someone somewhere has to make it work together. Could be the customer, more often is the business you work for. If the former case is our heaven the latter is more common and that's when a compromise must be found. We know already waterfall doesn't work, we know that sprints sometimes are just waterfall on disguise but someone somewhere has to make it work and I've never ever heard a word of wisdom on how you can sell Agile in our age.
This video focuses on the right mindset that a cohersive organization should have, kick ass communication and expectations. It nudges you to a right path to reevaluate good and bad in your team. I got a small wake up call for myself also but I am really happy that our team is very flexible and antonymous to changes. But it is oversimplifying a very complicated and delicate process. You kicked up the dust but you left everyone in the dark in the hopes of better future. Next time please also add where people can learn about these principles to execute positive action. For me, this video only brought small value from what it could have given. Overall, I do hope that this video will be seen by many people as it has a really good point. And to everyone who have too many meeting. Understand what are the real problems why your team is having those meeting and propose solutions to tackle them.
Very good point! I added my thoughts in to the ERRATA on where you should start off, but there's certainly a WHOLE video on where we could go from here!
@@NoBoilerplate Thanks I can't agree with you regarding process documentation. We have increased our focus on documentation to ~60h a month + once per week review with tech lead and lead BE developer. Direct feedback from them have been very positive. Our sprint velocity (features) in 6 months has increased over 50% and increasing each sprint. This has also freed up massive time from our developers to contact PO and other stakeholders for needed specifics. In addtion, our timeline is now very predictable and adaptable. From this, are we delusional about the positive impact and do you have a recommendation what we should do instead? From the ERRATA points we are doing all other points very similarly. Thanks!
I worked in a company with extremely good documentation written by full time requirements engineers (v-model) and then one that does bad agile with absolutely no documentation. Even though I like the ideas of agile, I like having good documentation even more. My current job is pure and utter chaos.
Check my ERRATA comment: I'm sorry I wasn't clear in the video: Process documentation is valuable! But working software is MORE valuable. User documentation and api docs are PART of working software.
@@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 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!
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.
I'm forty seconds into this video, and can I just say. "Agile sucks -- specifically the way it is understood in most companies around the world today." The scroll of truth here is _that means agile sucks_. If one user gets a thing wrong because they didn't read, it's user error. If _most_ users get a thing wrong "because they didn't read"... it's bad UX and you need to do user behavior analysis to figure out how to get users to the destination more smoothly. This is the same. If "most" companies don't understand agile, then sorry, it's agile that's the problem. EDIT: Okay I watched the whole thing. Despite being pretty negative above, I actually agree with every point made in this video (at least partly, some completely). And if you are willing to wrench control of the term "agile" away from scrum's clutches, then yeah, it's great.
Thank you for the update to the comment. It's a common pattern to see unrelated products or ideas trading on the good name of something else. (see: "Quaker" oats, "recyclable" vs "recycled", the erasure of the meaning of "socialism", etc. etc.)
You're really hitting the nail on the head with agile. Cargo cult is the perfect description. Unfortunately it's far from the only affected part of software development. There's a whole cottage industry of similar nonsense in other areas too, with people peddling books, courses, consulting, best practices, etc: clean this, something-driven that. Always without any evidence of usefulness, of course.
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.
Thank you, it's actually my old logo I use for all my projects (see the channel logo, and the one for my creative projects, NAMTAO) 'Agile' is what software developers call 'the scientific method', but we use a fancy name because we're special!
Individuals and collaboration over process and tools is hard man. Not once have I watched engineers go back and forth over a topic, forgetting the goal, the impact of the said change (negligible), and just weighing pros and cons over something that really doesn't make a difference. Another thing. We use checklists for our PRs. Why am I supposed to keep in mind every concern for that PR? Think about what changed, see if it concerns the items in the checklists. You use the checklist as leverage. Free up cognitive power for more creative stuff instead of menial stuff like remembering things. My principle is if it's not written down, it doesn't exist.
Totally agree, I really love a high-documentation culture in a team. As a part-time remote worker, if things aren't written down, they can't involve me! I don't think "individuals and collaboration" only means "talking". At least, I hope not!
Imagine you're doing project work, you're doing pre-sales and the customer asks you, "how much will this cost?" which is another way of asking how long it will take. What do you answer, without any estimation?
Hi, I am taking a course on adaptive project management and I wanted to share a perspective. Upper Management needs to know the course, and have an estimate to completion to fund the project. This is especially true when you are working for a consulting company and are billable to the client. They won't sign an open check. As I watched your video, it was refreshing to hear from a developers POV, but at the same time - concepts like not planning, or having a scrum to advise leadership of where the project is, or how much longer it will take is simply unfair to the sponsors paying for the project. How can I reconcile that?
With a separate process than Agile, don't fuck up a process designed for developers to move as fast as possible by adding features that make it worse ;-)
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
I'm afraid not! I'm so entrenched in the vim bindings that even though helix (and kakoune) has the right idea, selection SHOULD really come first, I can't get used to it - curses!
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.
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.
I do agree with most of what you said, although I think you didn't insist enough on the self-organizing team delivering a software of quality. Teams pressed by time will release buggy software, or one harder to modify later. Am I the only one hoping for a word about the amount of stress a team has to endure, in videos talking about Agile ? I have never heard it mentionned so far. Attention rarely seems brought upon so-called agile team like mine, where the manager decides alone which tickets get into the sprint or not, and can't care anymore about estimations because he accepted to set a delivery date ... Our team agency is removed since we don't get to chose what we work on, can't fix the bugs or spend time to improve the life of users. Quality is getting thrown out of the window since tests are not added to modified software. Problematic parts of the softwares are not reworked. It's exactly the "as soon as it work, ship it" mentality. Please help
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 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.
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.
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 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."
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!
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 ;-)
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.
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...
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.
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.
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
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
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!
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!
I build an OpenSource Profiler with one of my colleagues, and we had an extremely tight deadline. So we just puzzeld it together, figuring out what we needed on the fly. After we just managed to make it work before the deadline, I spend the last one and a half years to rewrite it as a sideproject, because now I knew what we actually wanted from the start.
In my experience, the third reimplementation of something is usually really good: one implementation to explore the concept (realizing your initial mistakes along the way), one implementation to build a decent version (realizing deeper defects along the way), one implementation to get really polished (avoiding e.g. most technical debt in the process).
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
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
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 :-)
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
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. ❤
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.
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.
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
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
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!
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.
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.
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.
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!
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.
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.
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
The most favourite and absolutely correct: just deliver a value.
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!
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 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
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 :-)
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.
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 have found what I think is a misunderstanding to "iterate code fast".
I've had software engineers developing a frontend app in days or weeks to show them to the stakeholder, just to receive a "thats not close to what we are looking for".
Planning ahead is NOT against agile. Having a quick scratching in paper session of 30 minutes that can help you understand the needs of the client and use that scratch to iterate the first time faster is indeed making your code better.
We should not only deliver code, but look for ways to iterate faster without sacrificing quality.
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.
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?
You know what they say: "The tradition of all dead generations weighs like a nightmare on the brains of the living."
Oof that's heavy.
I've heard a similar one: "I'd rather disappoint my grandparents than my grandchildren".
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.
Thank you for putting what I've been feeling for the past couple months into such clear language. Great video!
You're so welcome!
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!
My last job made me sit through a long-ass meeting every other day, and during the vast majority of days I had nothing to do. I either had to wait for my moron teammates or asshole management. This funniest part of this is that they PAID FOR MY AGILE CERT
It's a sickness
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
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!
This sums up the problems with the way we use agile really well.
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.
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.
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!
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
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 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!
I've been subscribed for a while but I just started *paying attention*. Outstanding content, I'm rebuilding my whole perspective tech stack.
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
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!
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
I stumbled upon a job description that included "agile daily *rituals*".
Still in shock
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…..
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.
Here is the agile interpretation I was thinking the same thing about. You explained it much better than me.😅
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!
Just wanted to let you know that you are my favorite tech-youtube channel and the only one that i would watch again and again, not because i dont understand, but because i love your voice and points... must have watched some of the rust videos like 5+ times.
Keep on fighting the good fight and take this comment for the algorithm : )
That's fantastic news! I was a bit apprehensive about releasing this video, as it's outside my usual type, but everyone's so nice about it! Thank you :-)
If you want to hear more of my voice, there's 10 seasons of Lost Terminal to enjoy, I'm so proud of it ua-cam.com/video/p3bDE9kszMc/v-deo.html
@@NoBoilerplate I was going to ask where you learned speaking like that, but had to do a double take, it does say SEASONS up there, jesus
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 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.
You would not believe the depth of argument, over an hour, I had with using number story points or t-shirt sizes. The other developer likes numbers, specifically golden ratio numbers, with arguments of arithmetic purity. I like my stories small, medium and large. It's all estimation anyway, I'd rather convey the gut feeling rather than some analytical numbers detached form the human experience of actually developing software. He conveyed the want and necessity of managers to track progress and work from developers. The sizes don't do that. But if my boss is relying on these numbers to gauge progress then he is too detached from the project to be an effective manager.
I too try to argue for t-shirt sizes: S M L.
I've been in teams that had a whole STORE of different sizes. 3XL I kid you not.
I now am fully converted to 1, TFB, NFC!
After 8 years of agile working, I've read the manifesto. I'm very tempted to print it and stick it to the door of the office.
Saying "hello my name is Tris and this is no boilerplate" is boilerplate
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.
5:15 Unfortunately, that only works when everyone on the team is motivated to accomplish the goal. Once you have people who treat the job only as a source of income and do the minimum amount of work required to not get fired, this no longer works.
Your content is always top notch quality. But this one, sir, is just so accurate... As a dev who suffered a lot from Scrum, I can't agree more.
We're all working in the code mines, being whipped by scrum overlords
I wonder how you can start a project without a rough estimate and a business plan and when you ask a consult from a software company all you hear are jargon words like MVP, hourly price and number of sprints with no warranties on what will be delivered.
I mean, Agile works when you are a hired coder with a wage but someone in some other office has to plan, needs estimates, writes contracts and SLA. Someone somewhere has to make it work together. Could be the customer, more often is the business you work for. If the former case is our heaven the latter is more common and that's when a compromise must be found. We know already waterfall doesn't work, we know that sprints sometimes are just waterfall on disguise but someone somewhere has to make it work and I've never ever heard a word of wisdom on how you can sell Agile in our age.
Scrum is lots of little waterfalls!
This video focuses on the right mindset that a cohersive organization should have, kick ass communication and expectations.
It nudges you to a right path to reevaluate good and bad in your team. I got a small wake up call for myself also but I am really happy that our team is very flexible and antonymous to changes.
But it is oversimplifying a very complicated and delicate process. You kicked up the dust but you left everyone in the dark in the hopes of better future. Next time please also add where people can learn about these principles to execute positive action. For me, this video only brought small value from what it could have given.
Overall, I do hope that this video will be seen by many people as it has a really good point.
And to everyone who have too many meeting. Understand what are the real problems why your team is having those meeting and propose solutions to tackle them.
Very good point! I added my thoughts in to the ERRATA on where you should start off, but there's certainly a WHOLE video on where we could go from here!
@@NoBoilerplate Thanks
I can't agree with you regarding process documentation. We have increased our focus on documentation to ~60h a month + once per week review with tech lead and lead BE developer. Direct feedback from them have been very positive. Our sprint velocity (features) in 6 months has increased over 50% and increasing each sprint. This has also freed up massive time from our developers to contact PO and other stakeholders for needed specifics. In addtion, our timeline is now very predictable and adaptable.
From this, are we delusional about the positive impact and do you have a recommendation what we should do instead?
From the ERRATA points we are doing all other points very similarly.
Thanks!
@@rrais9543 To be clear: I like technical documentation (api docs, code documentation etc) - what is "process documentation"?
I worked in a company with extremely good documentation written by full time requirements engineers (v-model) and then one that does bad agile with absolutely no documentation. Even though I like the ideas of agile, I like having good documentation even more. My current job is pure and utter chaos.
Check my ERRATA comment: I'm sorry I wasn't clear in the video:
Process documentation is valuable! But working software is MORE valuable.
User documentation and api docs are PART of working software.
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!
Not only working software, but software that can be worked on!
Absolutely - maintainable software is working software. Write-only software is garbage!
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!
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.
I'm forty seconds into this video, and can I just say. "Agile sucks -- specifically the way it is understood in most companies around the world today." The scroll of truth here is _that means agile sucks_.
If one user gets a thing wrong because they didn't read, it's user error. If _most_ users get a thing wrong "because they didn't read"... it's bad UX and you need to do user behavior analysis to figure out how to get users to the destination more smoothly.
This is the same. If "most" companies don't understand agile, then sorry, it's agile that's the problem.
EDIT: Okay I watched the whole thing. Despite being pretty negative above, I actually agree with every point made in this video (at least partly, some completely). And if you are willing to wrench control of the term "agile" away from scrum's clutches, then yeah, it's great.
Thank you for the update to the comment.
It's a common pattern to see unrelated products or ideas trading on the good name of something else.
(see: "Quaker" oats, "recyclable" vs "recycled", the erasure of the meaning of "socialism", etc. etc.)
I don’t think we should have multiple devs work on the exact same feature
You're really hitting the nail on the head with agile. Cargo cult is the perfect description. Unfortunately it's far from the only affected part of software development. There's a whole cottage industry of similar nonsense in other areas too, with people peddling books, courses, consulting, best practices, etc: clean this, something-driven that. Always without any evidence of usefulness, of course.
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.
Cool new logo. I barley know how to code, so no idea what agile or scrum is but I am here for it anyways.
Thank you, it's actually my old logo I use for all my projects (see the channel logo, and the one for my creative projects, NAMTAO)
'Agile' is what software developers call 'the scientific method', but we use a fancy name because we're special!
Individuals and collaboration over process and tools is hard man. Not once have I watched engineers go back and forth over a topic, forgetting the goal, the impact of the said change (negligible), and just weighing pros and cons over something that really doesn't make a difference.
Another thing. We use checklists for our PRs. Why am I supposed to keep in mind every concern for that PR? Think about what changed, see if it concerns the items in the checklists. You use the checklist as leverage. Free up cognitive power for more creative stuff instead of menial stuff like remembering things.
My principle is if it's not written down, it doesn't exist.
Totally agree, I really love a high-documentation culture in a team. As a part-time remote worker, if things aren't written down, they can't involve me!
I don't think "individuals and collaboration" only means "talking".
At least, I hope not!
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.
Imagine you're doing project work, you're doing pre-sales and the customer asks you, "how much will this cost?" which is another way of asking how long it will take. What do you answer, without any estimation?
Incredible! Thank you!
Thank you! Judging by your avatar, you're gonna LOVE tomorrow's video XD
Hi, I am taking a course on adaptive project management and I wanted to share a perspective. Upper Management needs to know the course, and have an estimate to completion to fund the project. This is especially true when you are working for a consulting company and are billable to the client. They won't sign an open check.
As I watched your video, it was refreshing to hear from a developers POV, but at the same time - concepts like not planning, or having a scrum to advise leadership of where the project is, or how much longer it will take is simply unfair to the sponsors paying for the project. How can I reconcile that?
With a separate process than Agile, don't fuck up a process designed for developers to move as fast as possible by adding features that make it worse ;-)
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
Thank you for a video that confirms all of my 'agile' biases :-)
Would love to see you make a video of you using Helix if you are still actively using it!
I'm afraid not! I'm so entrenched in the vim bindings that even though helix (and kakoune) has the right idea, selection SHOULD really come first, I can't get used to it - curses!
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.
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.
I do agree with most of what you said, although I think you didn't insist enough on the self-organizing team delivering a software of quality. Teams pressed by time will release buggy software, or one harder to modify later.
Am I the only one hoping for a word about the amount of stress a team has to endure, in videos talking about Agile ? I have never heard it mentionned so far.
Attention rarely seems brought upon so-called agile team like mine, where the manager decides alone which tickets get into the sprint or not, and can't care anymore about estimations because he accepted to set a delivery date ...
Our team agency is removed since we don't get to chose what we work on, can't fix the bugs or spend time to improve the life of users. Quality is getting thrown out of the window since tests are not added to modified software. Problematic parts of the softwares are not reworked. It's exactly the "as soon as it work, ship it" mentality.
Please help
I'm afraid you're not using agile, you're using it in name only. Show your manager my video and ask them what they think?