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.
I haven’t read your blog post, but I agree with your comment.
Unfortunately, Scrum is often misused. Why? Often, I think people don’t understand the problems that Scrum is trying to solve. So people implement Scrum poorly. And, when evaluation time comes, they blame everything but their lack of knowledge and skill regarding Scrum.
But Scrum is actually a framework to help you solve very common problems.
If you understand that, then Scrum becomes useful.
There’s a set of problems that teams will always have to deal with: how to choose what to work on, how to coordinate, how to know when something is done, how to see if your work actually solves the problems you’re trying to solve, how to deal with task-switching costs, how to deal with cognitive load, how to deal with complexity…
And those problems can be solved with Scrum. Or Kanban. Or any other Agile way of working.
What’s important is that it works.
Yeah, this is probably going to sound like a truism, but to avoid shitty Scrum, you need to resist management trying to alter the processes, but you should absolutely tweak the processes to account for the needs of the devs.
Basically, yet another reporting meeting does not help deliver the software faster. But more (or less) meetings for devs to sync what they’re working on, that can help, depending on your team’s specific needs.
There’s some insane ideas in there, like:
- Only release every two weeks.
- This includes bug fixes.
- Emergencies can be dealt with immediately, but any root cause analysis or deeper work on underlying issues must wait for the next sprint.
- If it can’t be done in 4 hours, it can’t be done at all.
- Don’t document things.
- Don’t write bad code. (Also: You must use classes and methods, and variable names must be words.)
- Rigid adherence to the “agile process” is required.
- The job of a software developer is to crank out code and nothing else, especially not design, testing, or documentation.
- Don’t even think about ethics.
That’s both rude and inaccurate:
“Only release every two weeks.”
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 includes bugfixes”
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:
“We found this bug on Thursday, and a fix in the works to have it patched for the next sprint due out next week”
…than it is to say:
“We failed to have bugfix/feature/whatever done by the end of the sprint as promised because our developers were taken off-task, catering to the latest freak out session by the COO”.
“Emergencies can be dealt with immediately, but any root cause analysis or deeper work on underlying issues must wait for the next sprint.”
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.
“If it can’t be done in 4 hours, it can’t be done at all.”
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.
“Don’t document things.”
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.
“Don’t write bad code. (Also: You must use classes and methods, and variable names must be words.)”
Yeah I stand by this.
“Rigid adherence to the “agile process” is required”
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.
“The job of a software developer is to crank out code and nothing else, especially not design, testing, or documentation”
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.
“Don’t even think about ethics.”
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.
First off, I don’t know you and I’m not accusing you of anything. But the document you wrote says what it says, and I’m standing by what I wrote.
“Only release every two weeks.”
No. Nowhere did I say that. In fact, the team I wrote this about worked on a 1 week sprint.
OK, cool. Make it “only release once per week” then; it doesn’t change my point: The article defines “sprints” as a deployment schedule. What kind of software are we talking about here? A website or similar provided “as a service” over the internet? Then why stick to a rigid one or two week release cycle? Or a traditional “run locally” application? Then weekly updates are much too frequent, I’d say.
(I did note the date on the post, but it didn’t strike me as relevant. My first contact with “agile” was in 2013 and our deployments were a manual process (later automated), but we did it without downtime and we never waited until the end of the sprint to release 20 finished tickets at once. In fact, I’ve never worked at a place that treats sprints as release cycles.)
“This includes bugfixes”
This is true. It’s is primarily because deviating from the commitment you made with the company to have x jobs done by the end of the sprint necessarily means being unable to meet that commitment.
No, I’m not talking about going bug hunting, I’m talking about releasing the (already developed) bug fixes. Again, if we “think of sprints as a deploy schedule”, then even bug fixes developed on day one of the sprint still need to sit around for a week or two.
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?
Now it’s my turn to say “nowhere did I say that”: When I mentioned root cause analysis and working on underlying issues, I meant actually doing that, not having a 6-person meeting. (Why would I ever hold a meeting?)
Consider the following analogy: On day one of the sprint, someone trips over a power cable, twists their ankle, and takes out a server. By the rules set out in the article, we would plug the server back in and apply pillows and ice packs to the ankle (i.e. fixing the immediate issues). But the rules wouldn’t let us ask who ran a power cable through the middle of a room, or move the power cable out of the way, or find a different power source for the server. We would have to wait one or two weeks for the next sprint to start and until then just live with the tripping hazard. (And in software there can be many “tripping hazards”, particularly when a team has undocumented, organically grown, manual processes.)
“If it can’t be done in 4 hours, it can’t be done at all.”
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.
That’s the same thing I said. Tasks that can’t be broken up into less-than-four-hour units of work can’t be done. How is that a misrepresentation?
“Don’t document things.”
I didn’t say that.
“[…] developers have only 3 responsibilities over and above writing code throughout the sprint. [daily stand-up, sprint retrospective/planning, figuring out WTF the client wants] Note what isn’t in that list: […] Documentation”
And no, this isn’t about commenting code. The article explicitly calls things like wiki documentation an “exercise in futility”. Later on, the “Documentation” section explains how to transfer knowledge to new developers: Have them work on various “components” and let them figure it out themselves (i.e. reverse-engineer the code). Knowledge only exists in people’s heads: “[…] if Daniel gets hit by a bus, the project can go on because Aileen, Charlie, and Aisha have all spent some time poking at the payment engine.” Written documentation isn’t even considered as a possibility.
“The job of a software developer is to crank out code and nothing else, especially not design, testing, or documentation”
It should not be a surprise that one would expect software developers to develop software. If you want design, you hire a designer.
OK, let me just quickly hire a network protocol designer, data structure designer, algorithm designer, API designer, and software architecture designer. Sure, some people would consider that to be part of software development, but not you, apparently: You’re doubling down on the “software development = cranking out code” thing.
Now, I haven’t been doing this for 27 years, but some places where I worked defined software development much more broadly: Programming, QA/testing, UX and UI design, user studies, requirements gathering, internal and external documentation, it all fell under the “software development” umbrella.
Testing is part of the process though, and I never said otherwise.
You did: “developers have only 3 responsibilities over and above writing code throughout the sprint” and none of them is testing.
“Don’t even think about ethics.”
FUCK THIS. Don’t you dare suggest to me that I wouldn’t demand ethics of everyone I work with.
“[…] developers have only 3 responsibilities over and above writing code throughout the sprint” and none of them is thinking about ethics.
Engineers have a responsibility to do right by the world they live in, and nothing I’ve mentioned in that post would suggest otherwise.
I suggest re-reading the “Talk Less, Code More” section. (You could also call it “Think Less, Code More”.) It emphasizes the smooth flow of simple tasks to be coded up, piece by piece, from “todo” to “finished” with a minimum of hassle. Where in that process is there room for friction in the form of thinking about (let alone questioning) the bigger picture?
So in short, shitty Scrum isn’t Scrum. Thx mate
