Nobody needs too "innovate" another stupid CRUD app though...
I kinda feel all the _actual_ innovation is doing things that align with Agile's underlying principals of valuing individuals/working-software/response-to-changes over processes/documentation/plans - while all th3e people who _talk_ about doing "Agile" rarely follow those principals, and mostly just mean "We have meetings we call 'standups', and negotiated deadlines that we call 'sprints'".
I agree. It’s sad. Agile principles are awesome, but by the time you run them through many company’s implementations of Scrum or SAFe or (God forbid) Jira, you may as well just do waterfall.
I don’t think waterfall is necessarily bad, that agile is always right, or that there aren’t other good practices. But practicing waterfall and calling it “agile” is rarely going to end well for anyone.
We do Scrum at my office. But really, it's just applying sprints to waterfall. We do get some shorter feedback loops to improve features before going live. But the whole scope is still set at the start of the project, and that scope needs to be completed at the end of it.
And to be very honest. It doesn't work if the people in the team don't think Agile. Your team needs to be able to self-reflect and try to improve themselves just as they'll do with client work in a sprint.
I mean it is a ️️hot-take but I don't regard scrum as any sort of subset of agile. Rather scrum emerged when big companies wanted to basically do what they were already doing, but call it agile. A framework emerged to teach these companies a “safe word” rendition of agile, don't worry it's only agile until you say “banana.”
You cannot appoint somebody to the strange title of “scrum master” (which I guess makes the rest of us scrum slaves?) to lead a process of “daily scrum” where we look together at a kanban board and make sure that we are “sprinting” and then turn around to insist that you value “individuals and interactions over processes and tools,” which is ¼ of the Manifesto. You have voted with your intention and your vote was to value your process and tools over trusting the individual developers and letting them have direct interactions with your customers.
Even the word “sprint.” I used to play Ultimate in one of the teams in the Dutch national league, it is a sprinting sport. The word “sprint” means exhaustion. It means stopping. If you jog around in Ultimate you lose, you have to rest, sprint, rest, sprint. If your model is “always sprinting” then do not tell me that you value “individuals and interactions.” And if you do value the latter please either (a) remove the metaphor “sprint” from your process or (b) add “rest weeks” after each sprint to “clean up” the mess you made! Anything else is lying to yourself.
The phenomenon of estimating “story points” is even worse, no? It is intrinsically about processes and tools and the idea of a developer having a phone call or face-to-face with the client directly to see if this feature request is actually accurate, deciding that it is not, and trashing it to open a different request... it's not just “do we claim those juicy story points when this happens?” but also “was part of your measure of ‘complexity’ the complexity of determining that the Ask did not meet the Need?” ...And so the fundamental idea of estimating a “todo” does not fit well with agile, whereas you can estimate “in progs” and “done” just fine.
And before you say “no by the time we estimate we should already know that we want the feature, devs should never have to talk to clients,” please be aware that this response explicitly abdicates another ½ of the Agile manifesto, “customer collaboration over contract negotiation” and “responding to change over following a plan.” The whole point of the Agile manifesto is that your kanban board is stale. Not because it's a kanban board, but because it is written down. Like one of the four principles (the last ¼ not covered in the above ¾) is explicitly anti-literary.
This is sort of “no true Scotsman” of me but my read is that the moment Agile was systematized, it died a little on the inside. It was a “screw your systems!” reaction that then got steamrollered by the real world, where “bullshit jobs” and middle management reign even though they bespeak a bureaucratic feudalism rather than a lean-and-mean capitalism.
Is there some sort of guidance/explanation you could point to for implementation of "proper" agile development? I'm really interested in learning more about it :)
So the vision statement is on agilemanifesto.org and to a lesser extent the "principles behind the agile manifesto" on the same page.
What I am challenging in the above is that there is a "lip service" given rather than a deep assimilation. So when the principles say "business people and developers must work together daily throughout the project" they mean that there should be an open-door policy, “hey Amanda I am working on the Estimating-Work-in-Process application and I was wondering what you do with ____” “Oh, that is not supposed to be possible,” type of interactions. The ‘lip service’ is “your boss will answer any questions at daily stand-up.”
Because these interactions are routine, the idea of needing constant scheduling and progress updates ideally ‘should be’ a lesser issue. People want progress updates to make sure that you are not spending all your time on Reddit, they will be able to see that more readily if they see you working.
The core of agile is anti-establishment thinking. One of the principles is “The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Elsewhere Don Wells elaborates on it, “Don't panic. With professional software engineers on our project we can relax knowing that the team will do what is needed to get the job done. Any activity needed with any combination of people will just get done without any further scheduling or ceremony. This is the spirit and benefit of a self organizing team.”
And so a fundamental idea of agile, perversely enough, is that you’re not going to have one size fits all, there is no one ‘proper implementation.’ There is just the way that you made it work. If you have different personalities it’s gonna express differently.
I am not being facetious here, though I realize it sounds kind of like it! Adam Savage had a great video a little while back about something unrelated—weathering prop money—where he took live questions from the audience, and one question was about “the best way” to make that money look bloody, and he answered in true artisan style:
> So, your question though, “what is the best way”... The answer is, there is no, there is no best way! There is the way you figure out how to do it. Yeah! That’s really the thing. It may be that you’ve gotta, like, take a brush and kinda work at a whole bunch of different bills, and then take the stack and then effect the stack, right?, I think that’s like a multi-stage process, and then you should do some tests with different paints and see, like, under the lighting conditions these will be seen—I don’t know if it’s for a theater or a film—does it communicate? Does it tell you that it’s bloody, dirty money? That’s the question to be asking, you gotta hold it up, look at it, [mimes looking at it and pausing and thinking] “does that sell to me?”—and ask other people, “does this sell?”... and like most of the time they’re gonna go, “no,” and you’re gonna keep on going. But it’s trial and error.
And like the fundamental story about agile is that agile is trial and error, it is about trying to work together as a team and being like “did that work” and the answer is usually “no, Leah is totally burned out after she had to work 60+ hours of straight development that one week,” or “Alvin is having trouble with nobody inviting him in, he wants to start contributing to this project and everybody is like ‘nah man we got it’ and he is being excluded” and you’re gonna have to reshape. There is a necessary aspect of vulnerability in other words in any proper development strategy whether top-down design-first waterfall or agile or something else.
There is no one agile software development process. There is a set of agile software development values. It is a values-driven approach, “how are we living up to our self-commitments today?” rather than “did I follow the appropriate procedure?” And thus it is quite anarchist at its fundamental core. This is probably why I am ragging on scrum in the end, scrum came in and said “there is a non-anarchist way to do agile” and I am sitting here like “uh, do you know what you just said?”
With that said, all the usual caveats, I understand that you want to be able to state what all is likely to be in an upcoming release and what all isn’t and this requires creating estimates and so forth. But perhaps the most damning thing is when estimates turn into deadlines. When an estimate becomes a deadline it gets padded and re-padded, then the urgency of the feature gets de-emphasized because you have such an abundance of time to do it in, so you spend a bunch of time up-front completing your “design doc” about what you are about to build and then someone asks to weigh in and “approve it” and you have reinvented waterfall.
You thoroughly explained exactly what I meant in my comment.
I've only seen scrum implemented as a planning tool. But the teams aren't truly agile.
> And like the fundamental story about agile is that agile is trial and error, it is about trying to work together as a team and being like “did that work”
This is exactly what I meant with needing the team to be able to self-improve based on experiences. You can trial-and-error velocities all you want. But if you don't employ that same agility on a deeper level it's never going to work anyway.
Ah, not to worry. Modern agile is just waterfall, but with shorter timelines to maximize overhead costs and minimize productivity. It makes sense when you realize that we pay employees for days to elapse.
Two weeks ago I heard a colleague say: "I'm a scrum master in a waterfall project". That was my last week at that IT consulting company and really confirmed my choice to switch to a career with more purpose.
I have a hunch that one of the reasons "Agile" becomes ruined is the complexity of the stack most teams are using. IIRC, the stories/tasks were originally meant to be able to be completed by anyone on the team with little help from specialists/others within a reasonable time (..including UI?). When the Frontend Engineer needs to wait on Design, coordinate with Backend (ex: discussing API), or even wait for the S3 bucket to be up, mini-waterfalls will be the easiest path to take.
The whole idea of waterfall as I know it is to have large-ish iterations (typically a couple months), which comprise of analysis, dev and testing stages. Is this different from what you have in mind?
