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.

@TobiDub

Жыл бұрын

Why the WIP limit? Do you think that each issue should be worked on by at least two people? Why not WIP limit

@NoBoilerplate

Жыл бұрын

@@TobiDub Pairing is really, really good.

@LoveLearnShareGrow

Жыл бұрын

@@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.

@someonespotatohmm9513

Жыл бұрын

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.

@NoBoilerplate

Жыл бұрын

@@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.

@NoBoilerplate

Жыл бұрын

I've started asking at the top of a meeting "what would happen if we didn't have this meeting?"

@rishatsharafiev

Жыл бұрын

Same, i've finally left my job and landed another one with twice bigger salary and it's not so annoying yet.

@gebbygeb3547

Жыл бұрын

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.

@BurtonJohnson

Жыл бұрын

@@NoBoilerplate I like, "By the end of this meeting, we will have"

@CalifornianViking

Жыл бұрын

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

@NoBoilerplate

Жыл бұрын

This is the way.

@Winnetou17

Жыл бұрын

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

Жыл бұрын

@@Winnetou17 there's no limit to the team size when it comes to working with Kanban. Why would it fall apart?

@vorrakedryom6547

Жыл бұрын

@@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

@LetsRocka

Жыл бұрын

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

@NoBoilerplate

Жыл бұрын

yup!

@75yado

8 ай бұрын

Even worse because waterfall has some phases which are usually omitted in the corpo Agile but they are crucial to get the work done

@akam9919

5 ай бұрын

Oh, and some pieces are replicated thrice or more with only one of them being up to date.

@boldvankaalen3896

4 ай бұрын

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.

@NoBoilerplate

Жыл бұрын

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

@NoBoilerplate

Жыл бұрын

Sneak in XP

@duncanedwards8258

9 ай бұрын

Hence one of my favourite expressions: "It is easier to get forgiveness than permission."

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

@NoBoilerplate

Жыл бұрын

get mad!

@CalifornianViking

Жыл бұрын

@@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

Жыл бұрын

@@CalifornianViking exactly right. Love planning. Hate estimation.

@benmerk4086

Жыл бұрын

@@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.

@NoBoilerplate

Жыл бұрын

@@benmerk4086 Hi Ben, you sound like one of the good ones, I've had the pleasure of meeting many in my career. My problem with estimating individual stories is that my feeling is that the bounds for error are well over 100% due to the extra stuff that happens during a sprint to get work done. Undiscovered problems and hold-ups, or the other way, with work that is surprisingly easy. Estimation at the story level is what I have a problem with, because it seems to me to be just as good as top-down estimation. And top-down estimation doesn't take up any of my expensive team's time. To be clear: story planning and kicking off I'm down with, seems useful. But estimating time or effort? That's a much more dubious value proposition for me, after 15 years of developing. 1/TFB/NFC might me 90% of the way there ;-)

We shared this video in the company and I talked to the dev team I work closest with if we should change anything, drop any meetings etc. They unanimously said that all the meetings are needed and that they really like the way we work. We are running 3-week sprints and do a production release after each sprint and the team likes that we can cherish the progress we made together. But in turn we keep all other meetings to a minimum: We only meet when there is something to discuss and make sure only the people attend that are involved in the agenda. Team likes it, customer likes it therefore I like it 🙂

@NoBoilerplate

8 ай бұрын

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!

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.

@NoBoilerplate

Жыл бұрын

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.

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.

@NoBoilerplate

Жыл бұрын

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!

@Flackon

Жыл бұрын

1.8x?

@NoBoilerplate

Жыл бұрын

@@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.

@bunny_the_lifeguard9789

Жыл бұрын

And then there is fireship always rushing through his videos like he has to run to the toilet 😂

@4cps777

Жыл бұрын

I watch him at 2x. My attention span is kinda nonexistent at this point

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!

@NoBoilerplate

Жыл бұрын

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 :-)

@watynecc3309

Жыл бұрын

@@NoBoilerplate Poggers

@albo4life6082

Жыл бұрын

@@NoBoilerplate I think you should realize fans like myself atleast… really appreciate and respect your knowledge on all things not just rust :)

@NoBoilerplate

Жыл бұрын

@@albo4life6082 Thank you so much for saying so 🙂 I'm excited, I'll try more ideas!

@MrPlaneCrashers

Жыл бұрын

​@@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.

Your point on estimation is a breath of fresh air. I always hated being asked to estimate how long something would take as I really never had a clue. Then I started following the advice of "however long you think it's going to take, double it" and all of a sudden people are asking me why everything is going to take so long. I don't know!!

@NoBoilerplate

Жыл бұрын

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.

@RedditSideways

6 ай бұрын

if you keep estimating things, and you still don't have a clue, it's probably, because you really don't...

The problem with Agile is the fact that they gave it a name, agile is supposed to be an adjective, not a noun.

@NoBoilerplate

Жыл бұрын

I like this explaination

@jan-lukas

8 ай бұрын

It's not what you do, it's how you do it

Several years ago, I found a decent metaphor for explaining software development to non-technical managers: it's not an assembly line, it's creative writing. No, seriously. Sometimes, our tickets are just correcting a typo, or a mis-ordered page. But most of the meat of our work is adding/removing/modifying entire chapters, or storylines, all while maintaining story cohesion and continuity. Now imagine that it's an entire series of novels, and you have multiple authors making large changes to the same book at once! I have still found plenty of terrible managers and companies that couldn't be convinced to give a rip, but some are willing to process that, and realize what programmers are expected to do

@NoBoilerplate

Жыл бұрын

Steve, you've hit the nail on the head: We're not factory workers, we're artists.

@borg_cube

Жыл бұрын

Brilliant comparison.

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

@NoBoilerplate

Жыл бұрын

Thank you! SAFe sounds just terrible!

@domincwild

Жыл бұрын

My previous company did this and it drove me completely insane. You saw some improvement you could make to the code base real quick? Think again friend. You need a JIRA for that, you need to discuss the work to be done, it'll cause re-testing, you have automated tests? Well it might break something. Can't risk that, even though it's not in production yet... Funnily enough, our JIRA's were terrible quality too. Vague boundaries for the work, we spent literally 4 hours a day "refining" tickets, that took realistically less time to implement than the hours we spent discussing them. Massive refining calls with the entire team for those 4 hours. It was an "I&P" sprint, innovation and planning and it was 90% planning. One of their innovative ideas to make our JIRA tickets better? "mini" 3 amigos (this is in addition to the regular 3 amigos the ticket goes through). Before you pick up a ticket, have ANOTHER MEETING you MUST HAVE a dev, QA and a business person to begin the work. Because that 4 hour discussion wasn't enough. One of our "senior" devs got so blocked on doing work for the project, he enjoyed working more on side-projects than the real project. Wouldn't even seek out and try to do the "real" work anymore. It was such a disaster. But makes for a nice'ol horror story. It really makes you appreciate proper agile, tearing back all the nonsense, cutting the crap, having a team that speaks their mind etc. Makes a world of difference.

While I do agree with many of the points in this video, I have been in projects where this breaks down, and where meticulous planning up-front was imperative for the projects success. Specifically, I would like to point out the "the cost of failure is nearly zero" statement. For example, when the thing you're developing is responsible for billing millions of customers correctly, there's really no room for error. Not planning at all, releasing a just-about-finished version, and hoping to get feedback from your customers is not an option. That's a great way to get sued and/or get the authorities involved, and the cost of that is huge. Similar issues when you have to make sure the thing you're developing follows any contractual or legal obligations, really. Also, "It's the only thing that works" is definitely, provably not true. People were doing software development successfully long before Agile came around. Maybe just chose the best tool for the job, instead of claiming there's only one true way of doing things, eh?

@NoBoilerplate

Жыл бұрын

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!

Variety from no boilerplate. I love this. Keep this up

@NoBoilerplate

Жыл бұрын

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

@lukivan8

Жыл бұрын

@@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)

@NoBoilerplate

Жыл бұрын

@@lukivan8 Fantastic, share it with me when you're published!

@lukivan8

Жыл бұрын

@@NoBoilerplate Will make English subtitles just for u

@NoBoilerplate

Жыл бұрын

@@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

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.

@errrzarrr

Жыл бұрын

A testimony from an ex- High Priest of the Sacred Bureaucratic Cult

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?).

@NoBoilerplate

Жыл бұрын

Really great take, thank you.

@donparkison4617

Жыл бұрын

"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.

@dwmichaels

Жыл бұрын

@@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.

@donparkison4617

Жыл бұрын

@@dwmichaels Agree completely.

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.

@absalomdraconis

Жыл бұрын

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).

Incredible work. You've made extremely valuable content from the start, and I look forward to seeing what's to come.

@NoBoilerplate

Жыл бұрын

Thank you so much Chandler, this was a bit of a risk for me, so it's great to hear :-)

"Working software over comprehensive documentation" is good sometimes, but a more consistently valuable goal is to have a good balance between maintainability and immediate progress. It's the multi-armed bandit problem: "a fixed limited set of resources must be allocated between competing (alternative) choices in a way that maximizes their expected gain, when each choice's properties are only partially known at the time of allocation, and may become better understood as time passes or by allocating resources to the choice." (Wikipedia) However, I think agile forgoes this conclusion because of the role us devs often find ourselves in. The customer is always right, and if they requested something, they will get it. If the product they recieve makes no sense long-term, that's on them. They don't understand the code (they may not even have it), so at a certain point, if they want features, they will need to wait for the necessary refactoring. If the people who wrote the code are having a hard time maintaining /adding to it, then good luck finding a replacement who can do it faster.

@NoBoilerplate

Жыл бұрын

Totally agreed, the manifesto authors knew that "working software" is "maintainable software".

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

@NoBoilerplate

Жыл бұрын

ouch!

@errrzarrr

Жыл бұрын

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.

@BigheadGenius

Жыл бұрын

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.

@absalomdraconis

Жыл бұрын

@@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.

@luciojb

Жыл бұрын

"the code is the documentation"

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.

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.

@NoBoilerplate

Жыл бұрын

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.

@errrzarrr

Жыл бұрын

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.

@BigCarso

Жыл бұрын

Well no, I've had the opposite experience. Scrum has been the best process I've worked with.

@BigCarso

Жыл бұрын

@@errrzarrr That isn't part of agile or scrum. That's just managers being dicks

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

Жыл бұрын

Yikes!

@dwylhq874

Жыл бұрын

​@@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. ❤

Straight to the point, no bs, just pure knowledge. I love your work! ❤

@NoBoilerplate

Жыл бұрын

Thank you!

Nice switch up of content! Would love to see some Obsidian content from you soon :) On the topic of agile: our team decided to change the approach from a more scrum oriented version too, we still have some meetings but are a lot more chill about doing meetings if we would rather focus on coding. Your point on the story points has piqued my interest, I might bring that up, because I really don't see much of an advantage in the numbers too, but TFB and NFC are good to mention on a user story!

@NoBoilerplate

Жыл бұрын

Yeah, that was new to me too. Basically it's "yes this is a story" "too big" "more info needed". I love it.

One of the most interesting video i've ever seen. I've always hated SCRUM, and had become resigned to the (mis)idea that SCRUM = Agile, this video literally changed my mindset, thank you!

@NoBoilerplate

Жыл бұрын

oh my pleasure! It's a wild industry we're in, right?

@BigCarso

Жыл бұрын

Well to be honest a large part of scrum comes directly from the agile principles. Standup and retros are specifically mentioned in agile principles.

@NoBoilerplate

Жыл бұрын

@@BigCarso which agile principles? agilemanifesto.org

I agree with estimations, and the moral duty that if it's simple no need to plan it. We use estimations for stakeholders and for us to gauge relative difficulty. If this is a 3, and the next one takes significantly more work it's a 5 . If the next one has the same amount of work, but it involves other teams, other stakeholders, we bump it up. I mean these are heuristics more than anything. I don't care how management uses them. I value processes a lot. Should I spend all day writing to people in the slack channel reporting bugs on the website? Or should I have a workflow for them, to open a ticket, mark it as urgent or not, we pick it up, they can folllow process, they must fill in all fields to describe the bug. Retro if used properly can be used to get honest feedback, bring improvements and the team together, if it's not hijacked by someone else wasting time talking about a task.

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.

@sids911

Жыл бұрын

dumb me... its code to the moon's video if I remember correctly.

@NoBoilerplate

Жыл бұрын

Yeah! I contacted Ken and we did a cross-promo, it was very friendly :-)

@NoBoilerplate

Жыл бұрын

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.

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.

@NoBoilerplate

Жыл бұрын

Thank you so much!

Love your topic / analysis / discussion videos!

@NoBoilerplate

Жыл бұрын

Thank you so much!

OMG, you nailed this on every point. Thank you! There's no telling how many days of my life I've wasted in daily stand-ups listening to people try to make it seem like they were productive since the same time yesterday. The micro-managers just love it. And out of all those thousands of meetings, I would wager I've heard something useful in maybe five of them. To management, Agile is synonymous to Scrum, instead of Scrum being a subset. I would like to try Kanban, but no one seems to know what that is. And the Scrum process becomes the new religious dogma. You estimated more hours of work than remain in the sprint because something is taking longer than expected? Oh No! The burndown chart is now in the red! You better work late to fix that for the arbitrary sprint deadline so our retrospective charts look pretty! This shit has really ruined my love of a career in software development. I currently work in the defense sector. You can imagine how bureaucratic any process becomes in an industry that's tied so close to government, the epitome of inefficient "process". I can't wait to retire.

@NoBoilerplate

Жыл бұрын

That sounds tough my friend. See if you can get into a smaller, younger company, and in the interview ask them how many hours of meetings they have in a week. If they don't know, thank them for their time.

Thank you for putting what I've been feeling for the past couple months into such clear language. Great video!

@NoBoilerplate

Жыл бұрын

You're so welcome!

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.

Thanks for the shoutout, and fantastic video!!! Agile can definitely be a footgun in the wrong hands.

@NoBoilerplate

Жыл бұрын

My pleasure, your videos are so great, Ken! Thank you for making them :-)

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!

@NoBoilerplate

Жыл бұрын

My pleasure!

I've been subscribed for a while but I just started *paying attention*. Outstanding content, I'm rebuilding my whole perspective tech stack.

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.

The most favourite and absolutely correct: just deliver a value.

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.

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.

You know what they say: "The tradition of all dead generations weighs like a nightmare on the brains of the living."

@NoBoilerplate

Жыл бұрын

Oof that's heavy. I've heard a similar one: "I'd rather disappoint my grandparents than my grandchildren".

I love this, thank you! I've stumbled into becoming a programmer using no-code tools and now I'm building software for clients. Since building software was a hobby and the no-code space is tiny and somewhat disconnected/ostracised from CS circles I have found it hard to understand how to take an idea from a client and deliver. Estimation and over planning is truly a killer. Thanks again this helped me think a lot clearer about all this.

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.

@NoBoilerplate

Жыл бұрын

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

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)

@NoBoilerplate

Жыл бұрын

OOH thank you, gonna remove that now

@ahmed.systems

Жыл бұрын

@@NoBoilerplate Thank YOU for the quality content, that's what makes me wish for this channel to grow big

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.

@NoBoilerplate

Жыл бұрын

I'm so pleased, thank you!

@rancidbeef582

Жыл бұрын

@@NoBoilerplate Yeah, I'm definitely going to check out CTTM. And I've really enjoyed your Rust videos as well!

A friend of mine once said that Agile is a fancy name for "engineers talking to each other". By cutting out the middle man, i.e. management (which I prefer to call "manglement"), the managers realized that their jobs were pointless and that they are dead weight to the company. They got business degrees, not engineering degrees; "doing things" isn't in their playbook. Of course, they have to justify their employment somehow, rent isn't gonna pay itself, so they take the only option they know of: forcibly inject themselves into the engineers' workflow through meetings and convoluted protocols. They then hoist this bastard procedure above their heads and shout "Agile!" or "EOS!" while the engineers decry vital hours of lost development time.

@NoBoilerplate

6 ай бұрын

Exactly right. A Pig and a Chicken are walking down the road. The Chicken says: "Hey Pig, I was thinking we should open a restaurant!" Pig replies: "Hm, maybe, what would we call it?" The Chicken responds: "How about 'ham-n-eggs'?" The Pig thinks for a moment and says: "No thanks. I'd be committed, but you'd only be involved." No chickens are allowed to speak at my standups.

I would add that, while "working software" is important, working software that doesn't add value (eg, solve a problem, meet a need) is by definition valueless. You're not done when you release working software, you're done when the value exists (eg, problem is gone, need is met). Working software is your current best guess at what might provide that value, but it's not the point. It's merely a measurable, doable means to that end. Put another way, working software is a lead metric; value added is a lag metric. Value is what matters, but you can't directly add value: you can only directly make software. So make software. But if the indirect but actually-important value doesn't result, go figure out what software to make (or rework or some other non-software solution) until it does.

Here is the agile interpretation I was thinking the same thing about. You explained it much better than me.😅

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.

@NoBoilerplate

Жыл бұрын

Couldn't agree more, maintainable, well-documented software is working software

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.

@NoBoilerplate

10 ай бұрын

love planning, hate estimation!

Incredible! Thank you!

@NoBoilerplate

Жыл бұрын

Thank you! Judging by your avatar, you're gonna LOVE tomorrow's video XD

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.

@NoBoilerplate

Жыл бұрын

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

This sums up the problems with the way we use agile really well.

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.

@NoBoilerplate

11 ай бұрын

Now you're thinking with portals!

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!

@NoBoilerplate

8 ай бұрын

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 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.

@NoBoilerplate

Жыл бұрын

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.

What an excellent and clear summary. You cut through so much noise and bullshit on this topic. Well done. Saving this to show managers

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?

I follow your very useful videos and I also follow Allen and Dave and Martin. I do dislike Scrum, Ceremonial Agile, SAFe (ugh!), and more than anything Jira and certifications. There is one way to learn and do Agile: Do agile! And there is one way to learn it (besides doing it): do it with people who have done it before and successfully if you are lucky to be in such a team. BUT, one thing I guess we overlook is the FORMAT. In the long term, Format is more important than Content! That is why religions with rigid ceremonies last and liberal approaches to religion ceremonies die. In software design, this is projected in Conway Law. Maybe, the only design law in software that I am aware of. It is important to have simple but (kind of) rigid formats, processes, chart, team formation, communications, version control, release cycles, CI/CD in order to have a successful product for a very long time.

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.

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.

This is my favorite video of yours, bravo!

@NoBoilerplate

Жыл бұрын

Wow, really! Thank you so much, I was really worried about doing something new!

Absolutely loved this ❤

Thank you for a video that confirms all of my 'agile' biases :-)

Fully agreed that too much process and ceremony can be detrimental to progress. But on the other hand, in my humble experience, certain tools, agreed upon ways of working, documentation, feedback from both customers and from peers and some ways of making sure devs and dev teams aren't working on duplicated, competing stuff or some stuff that should be cared about goes without caring are a must. So is connecting all that jazz to the other parts of the organizaion. On the other hand I'm all for competing prototypes, but we should have everyone commit to the one with most long-term merit and coherence for the overall solution. Too often I feel like "being agile" is used as an excuse for not doing any planning and not coordinating work with the company as a whole and all sorts of unmaintainable gung-ho short term hacks that screw you over in the long run. I feel that there's a lot of good stuff built into Scrum and most of the events seem to have a valid purpose. I would be very interested experiencing a reasonable implementation. I have never witnessed Scrum in action myself.

@NoBoilerplate

Жыл бұрын

'being agile' does indeed tend to cover a multitude of sins - I hope you've seen I'm arguging for an evidence-based approach. If scrum works for your team, great! If a heavyweight process works, great. It has to WORK for you - there's no one-size-fits-all, but there doesn't have to be.

@jkasee

Жыл бұрын

@@NoBoilerplate Thx for the reply! :) Working as a mixed IT admin and software developer for a programming house that also does electronics and device manufacturing and very much doesn't forcibly restrict your role inside one particular box sure puts a whole lot of spin on thinking about these matters and grants an unbearably wide perspective on many types of issues and viewpoints. I try to think about it all too much for my own good, but hey, being holistic is a good thing right? And it sure doesn't get boring. Now if only I could grasp all of it or at least the most significant parts from all over the biz and make some concrete good come out of all the pondering and wondering :D Or die trying. Work in progress.

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 : )

@NoBoilerplate

Жыл бұрын

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 kzread.info/dash/bejne/omeWpqdym9bgfcY.html

@PLay1Lets

Жыл бұрын

@@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

this was great, thank you

@NoBoilerplate

Жыл бұрын

You're very welcome!

I stumbled upon a job description that included "agile daily *rituals*". Still in shock

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!

@NoBoilerplate

Жыл бұрын

My pleasure, I'm sorry I don't have many answers for you!

In my previous org I used to spent more time in filling data on our scrum project management tool Targetprocess then actual development.

@NoBoilerplate

Жыл бұрын

Terrible!

@errrzarrr

6 ай бұрын

Ah, the proverbial _People over processes_

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.

@NoBoilerplate

10 ай бұрын

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.

@transatlant1c

10 ай бұрын

@@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…..

I do agree with most of the points on this video, but I can’t seem to understand the “do not plan tasks and don’t estimate them” I am a software engineer that wants to not only understand what I’m gonna be working for how long, but most importantly when can I expect something else to be done for me to continue it. And I don’t believe pair programming or always asking is the answer here 😅

@NoBoilerplate

Жыл бұрын

To be clear, I only said don't estimate. When planning takes less time than doing the task, there could be value for your team, for SURE. It's when planning takes longer than the task that I get frustrated!

@NathanHedglin

Жыл бұрын

Estimates are worthless if you do nothing with the estimates. Just prioritize.

I'd very much appreciate your perspective on how to address nonfunctional requirements in the context of agile (or whatever) development. I'm a security guy, and it's really hard to sell customers, or even other engineers, on a "feature" that just consists of "stuff not breaking." That's applicable to security in particular, but also in general to reliability concerns and architecture work, as well as handling technical debt. Usually the customer can't give useful feedback (because it works fine if they're not pushing to prod, and ideally all they see is things not breaking), management doesn't understand why it can't just be handled in the same style as acceptance criteria, and engineers don't want anyone bloating their tickets' AC with things they can't directly test for.

@NoBoilerplate

11 ай бұрын

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.

Fresh air, thank you! Thoughts on Next.js 13 and Turbopack?

@NoBoilerplate

Жыл бұрын

Thank you! Not tried them, any good?

@Flapjack4795

Жыл бұрын

@@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!

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.

@NoBoilerplate

Жыл бұрын

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.

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.

@NoBoilerplate

Жыл бұрын

We're all working in the code mines, being whipped by scrum overlords

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.

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

Were being taught agile through scrum, where I'm studying CS, but I've often felt that it was impossible to estimate tasks that involve technology you haven't even learned. This has lead to us ditching most of the ceremonies of SCRUM, and instead focusing on getting work done. This however lead to another problem, where the less experienced members of a group end up stuck, confused and/or left behind, since they rely on a lot of the planning for certain tasks, in order to break down the given problem. So as a student I feel kinda stuck between these ideas. Any ideas on how to handle such situations, and what is your opinion on agile development from a students/learners perspective?

@NoBoilerplate

Жыл бұрын

Normalise task kick-offs. "Hey folks, I'm about to start task X, Could I have a few people to kick me off and get me going on it? Thanks!"

@arthurderyckere8732

Жыл бұрын

Pair programming

@NoBoilerplate

Жыл бұрын

@@arthurderyckere8732 LOVE pairing. A core part of XP, which scrum ruined.

@rancidbeef582

Жыл бұрын

I wondered how schools were handling this, since agile wasn't really a thing when I was in school. Hell, we never covered anything about managing / planning large projects. It was always just one-off programming assignments. Actually thinking of my first real job after college, we basically did a simple "agile", it just wasn't called that. We'd have meetings when necessary to plan stuff and go to work. We'd have impromptu meetings whenever needed to clarify issues or ask for help. It was awesome.

@NoBoilerplate

Жыл бұрын

@@rancidbeef582 Agile's basically just the scientific method. Hypothesis, experiment, theory or repeat.

Nailed it! No scrum, build/deliver direct to end-user - great, but in my company, engineers are shielded from the end-user by a layer of technical management. It makes it this much harder to penetrate this bubble.

@NoBoilerplate

Жыл бұрын

So counter-productive!

This video should be mandatory viewing in every software company anywhere 💯

@NoBoilerplate

Жыл бұрын

Thank you so much!

I have to disagree (or I misunderstood). Maybe those are good ideas for doing agile alone, but not in a team. I find scrums very valuable to quickly exchange ideas and share the overall status of everyone, without it we would all run about like oblivious beheaded chickens and not benefit from others' experience. And I don't know if the video is meant at some specific projects, but at work we're paid with money and so budgets have to be estimated, there is nothing for it. Estimations are easy and fun to do, and in my experience, we often found potential problems when evaluating story points, that we could eliminate before starting working on it (and avoid worthless work).

@NoBoilerplate

Жыл бұрын

I love standups (ie scrums). Scrum *the method* was confusingly named for them, not the other way around.

@phenanrithe

Жыл бұрын

@@NoBoilerplate I meant the method. The retrospectives have also brought great changes in the CI/CD chain and other areas - they're good to vent too, sometimes, just don't tell anyone I've said that 😅 There's no need to make those meetings very long or very often. In the end, those are tools, and nothing is universal so I think that's up to the team to adjust them to their needs and bend the rules. I sure agree that too many meetings isn't good.

@rdean150

Жыл бұрын

Estimates are not easy or fun when TLs and PMs treat story points as concrete timeframes, and estimates as promises to have the work completed by that date.

@phenanrithe

Жыл бұрын

@@rdean150 Then they have not understood how it works... Anyway dates are set by contract negotiation and rarely match the estimation. Pressure happens all the time, no matter what type of project management is used; it's just the client's stress that inevitably comes down the chain. It's expressed differently depending on the company, some bosses can make it very unfun indeed. *But* at least the story points are estimated as a team, and not imposed by a PM who doesn't necessarily have a grasp of the whole picture.

I’ve been programming to 32 years. You are 100% correct 👍

@NoBoilerplate

Жыл бұрын

Thank you!

I agree that the overhead and ceremonies are an excessive veneer of corporate control. Nevertheless, those come from two fundamental realities: 1) businesses need to finance R&D and ensure return on investment 2) customers have timelines for delivery, so promised delivery dates are important for customer service So the "you're doing agile wrong" says to me "I'm an artist why don't people pay me for what I want to make". There's a bit of entitlement to the sentiment. Are there ways to bridge this? Yes, and it involves devs and product owners spending more time with customers and understanding what they want, and why they want it, and why they want it when... straight out of the horse's mouth. The dev team needs to be part of the feature bidding process.

@NoBoilerplate

9 ай бұрын

We completely agree on the best way to do it right: Early customer feedback, straight from the horse's mouth. But estimating how long that best way will take is VERY difficult. Ask a poet how many poems they can write in a year, they will say "I literally cannot tell you" Ask a developer how many features they can write in a year, they will say "I literally cannot tell you". I'm not being entitled, it's just how it works, and anyone who tells you otherwise has something to sell you.

@cassiuslives4807

9 ай бұрын

@@NoBoilerplate well my finance office will ask "how long will it take to build the feature or meet the requirement", and the customer will ask "how long will it take for you to keep your promises".... ....a poet can shrug and say that "I literally cannot tell you" but then both the board and the customer say "well then I literally cannot pay you." ... and that's before CyberSec run a linter over the code and CICD pipeline and insist that it has to be fortified before it's suitable for Production deployment.

@NoBoilerplate

9 ай бұрын

@@cassiuslives4807 I don't doubt there are ways to give estimates to those people, both time and money. The agile manifesto does not say anything about that, and cramming in estimation into it causes a great deal of problems.

Would love to see you make a video of you using Helix if you are still actively using it!

@NoBoilerplate

Жыл бұрын

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!

You my dude are rapidly becoming one of my favorite agilists of all time. Thank you for renewing my faith that others out there get it

@NoBoilerplate

6 ай бұрын

Thank you! I wondered if you'd watch this video after the plain text one, I'm glad you did!

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

@NoBoilerplate

Жыл бұрын

It's a sickness

As a beginning project manager who now mostly helps with small tasks in ict, its good to hear. Im not a programmer but i like scripting and automating. I hope to not become like the dreaded managers that exist and find ways to use agile that work. Thanks for this!

@NoBoilerplate

8 ай бұрын

The best PMs I've worked with have understood the manifesto clearly, and nearly made themselves invisible by educating the team how to be self-organising. Do read these two short books if you've not already, excellent practical applications of agile ideas: - Rework - Remote

@Voljinable

8 ай бұрын

@@NoBoilerplate thanks for the recommendation! Are the books by jason fried & david heinemeier hansson? I luckily got a giftcard for books from work so ill definitely be buying them!

@NoBoilerplate

8 ай бұрын

@@Voljinable You've got it! They're from 37 Signals, the company that makes Ruby on Rails!

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.

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.

@NoBoilerplate

Жыл бұрын

Good documentation is part of a good system, absolutely.

I really like your videos, but this time I feel the need to write a comment because my jimmies are a bit rustled. First of all, I 100% agree that what's currently out there in the industry has long stopped being (or never was) "Agile" in the original sense and instead is a bullshit marketing term for management, making things worse than better. That being said, i doubt that just following the Agile Manifesto is enough to lead us out of the software development process jungle. - The reason the Agile Manifesto has survived for as long as it has is because it is not really actionable (and that's ok, its purpose is to outline the fundamental values of agile work). - Even for pure software projects, people struggle to translate the Manifesto and its 12 principles into actionable steps for the trenches of the software development industry. Even the most fundamental question, "what is valuable?" is extremely hard to answer and "involve customers" is only the beginning. - Many software projects (I'd argue the vast majority) are entangled with domains that have longer cycle times like certification, electronics, hardware etc. requirements and constraints are coming from. - I don't know what "working software" is. Is it when the customer is happy? Is technical quality part of it? Maintainability? I don't want to sound unfair because it's a 8 minute video which can't just solve a methodological question of the past 40 years. I guess what I am trying to say is that we are still far away from a methodology where we can say "do that and you'll get a good software product".

@NoBoilerplate

Жыл бұрын

Thank you for your comment, good to chat - I totally agree, my video mostly points out what is currently not working, rather than provide answers. The FIRST STEP is to realise that scrum/kanban/solid isn't the only way to do it - the way to do it is to start with your exact problem and domain, understand the agile principles, then work your way up from there. As you say, if you're bound to long lead times or hardware or government policy, you will work your way up to something that builds those immutable foundations in. But you'll never know if you don't start from the manifesto and work up! :-)

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.

@NoBoilerplate

Жыл бұрын

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!

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.

@NoBoilerplate

Жыл бұрын

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!

@rrais9543

Жыл бұрын

​@@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!

@NoBoilerplate

Жыл бұрын

@@rrais9543 To be clear: I like technical documentation (api docs, code documentation etc) - what is "process documentation"?

Thank you for respecting us by not making us put the video on x2 speed, rather pause sometimes haha

@NoBoilerplate

Жыл бұрын

My whole channel is written like this - it's indeed about respect :-)

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?

@NoBoilerplate

Жыл бұрын

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!