As someone who worked in an actually agile team years before the project managers co-opted the idea and contorted it into “Scrum” I feel this comic in my bones.
It is absolutely maddening how these people have perverted a system that worked so beautifully into the concentration-breaking wasteland we have now just to make themselves feel relevant.
While I’m presently a fan of Kanban, my happy agile experience was under sprints. If anyone is curious what that looked like, I’ve written about it here.
That’s both rude and inaccurate:
No. Nowhere did I say that. In fact, the team I wrote this about worked on a 1 week sprint. And as I said, I generally prefer kanban these days, but note the date on the post: this was essentially before continuous deployment was in common use, so sprints were very common and deploys were often a manual process that had to be greenlit by management. Many companies still do something similar. It is far from “insane”.
This is true. It’s is primarily because deviating from the commitment you made with the company to have
xjobs done by the end of the sprint necessarily means being unable to meet that commitment. If the bug is catastrophic, you obviously have to fix it right away (this isn’t religion, use your brain), but doing so busts the sprint and that has a real cost so yes, bug fixes should be delayed when possible. What I said was to show discipline in keeping “can you just fix this?” out of the sprint because it can introduce unexpected behaviour (new bugs!) and undermine your relationship with the client and sow frustration and discontent with the team as they’re driven to context switch.It’s much easier to say:
…than it is to say:
Absolutely. Are we here to get work done, or throw everything out the window to sit around and talk through a 6-person meeting whenever something goes wrong? You can, for example schedule a post-mortem for the next sprint when something breaks, but (a) more often than not, this can be handled in retro, and (b) if you need something bigger, then there’s no way you know everything right away anyway.
That’s a gross misrepresentation. What I said was that a job must be limited to roughly 4 hours of work. If that job is going to be more, then you should break it up to allow the work to be spread around.
I didn’t say that. What I said was that much of the time, people waste time/energy on writing documentation that is shortly out of date. What I didn’t say however is that I meant “commenting your code” here rather than “documentation”. I will die on the hill that most code comments are a waste at best, and a dangerous lie at worst, while obviously user documentation is very different and obviously important. It should however be listed as a ticketed job and therefore added to the sprint.
Yeah I stand by this.
Yes. That’s the whole point. You be as rigid as possible (within reason, again, use your brain). Rigidity provides structure and manages expectations on both sides. Being flexible leads to a mess. I know this because I’ve been doing this for 27 years and it has been my experience everywhere.
It should not be a surprise that one would expect software developers to develop software. If you want design, you hire a designer. Testing is part of the process though, and I never said otherwise. Don’t be shitty. I’ve noted documentation above.
FUCK THIS. Don’t you dare suggest to me that I wouldn’t demand ethics of everyone I work with. You know nothing about me, or my career, or what I’ve sacrificed to stay on the right side of the moral line. Engineers have a responsibility to do right by the world they live in, and nothing I’ve mentioned in that post would suggest otherwise. This was a post about building an efficient team capable of building great things quickly and well, while keeping the client happy with the progress. Of course you should refuse to do evil on the job. That should go without saying. Your decision to pretend that I care nothing about ethics says more about you than it does me.