Are you totally anti process? If not, which process do you find more palatable than scrum? Your comment is eye opening for me because I don’t know that I’d find a job if I decided scrum was a dealbreaker. What kind of projects or companies do you target that don’t have some flavor of scrum?
I’ve always felt scrum adds value for new teams who haven’t worked together or on greenfield projects in a space the team hasn’t worked before. That’s when the standups identity impediments. That’s when retrospectives uncover process or people issues. Once the team hits a stride it’s time for the training wheels to come off and then it’s just a Kanban board.
If you’re looking for a book — shape up — from basecamp goes through how they develop software and it looks great ! I am giving it a try. It’s very agile but not scrum.
I also agree that after a team gels together there’s no need for a lot of the overhead that comes with scrum.
My experience in organizations have always been to continuously shape the process depending on how the team feels about it and not call it scrum
We've been using this since late 2019, and generally been loving it. The concept of things being bets, plus fixed-time variable-scope are amazing, imho.
Not speaking for OP but agile, straight from the manifesto, itself is anti-process, at least in the sense where...
> If not, which process do you find more palatable
Is a cogent question.
Which process do /you/ find productive and helpful? What would you change? What would you emphasize? Process is a tool to serve you and your peers and your stakeholders. Not to pay fealty. Not to choose sides. It can be picked into pieces and rearranged. It can be recalled or reorganized whenever it’s unsuitable.
Exactly. Sorry for the ambiguity in my wording. I meant that the manifesto (like teams that do well adopting/reflecting it) is against proscribed process.
I don't think that's true, it's "people over processes", it doesn't imply a "no processes" stance, just that you shouldn't _force_ a process and you should adapt.
IMO that's what the agile manifesto is about: adapting.
But that's the opposite of my experience with agile and Scrum in the companies, where it is used as an excuse for non tech managers to enforce what they feel works better for them. In terms of control or, in some cases, micromanagement.
I've never had an issue communicating with a team without scrum, even when very new. On the other hand, communication gets worse with scrum, in my experience. Because everyone knows that the meetings are the time to communicate problems, they often delay all communication until the next day. And in some cases the morning meetings drag out to noon because that's when all the communication is going on, when it really just involves 2-3 people.
Individuals and interactions over processes and tools.
If the team likes scrum thats fine but picking scrum vs kanban, or bitbucket vs gitlab vs cvs, those are details a team cam and should be in charge of and revisit whenever they feel like. Because all that matters is working code, and what gets you there is skilled people that communicate well.
Working code is not all that matters, typically a business needs some predictability in output in order to plan ahead. If the business can’t function well because delivery is unreliable, sooner or later there won’t be any money rolling in to fund developers writing that code. Not every company will have enough ”skilled people that communicate well” for this to be an automatic byproduct of developers doing their thing, especially in larger or immature organizations.
> typically a business needs some predictability in output in order to plan ahead. If the business can’t function well because delivery is unreliable
the problem is that this assumes that estimates can be accurate, which in some projects may be the case, but in general there are always unexpected problems, things you didn't know you didn't know, etc.
If it happens that a company goes under because they lost all income because there was no deliverability, the problem was the company had the wrong team of engineers. Either too much "isolated geniuses" or too much inexperienced. Sometimes also happens that the management decides the way of doing work without technical involvement. Even companies I've been that decided to rewrite a mature and solid big piece of software, because they "needed to use more strategic technologies". Meaning, the technologies that were the "cool thing to use if you are a cool startup". And they use Agile (so they claim).
It doesn’t assume that estimates are accurate in that they need to approach perfection, but it does assume that good processes and tools can help make them reliable enough to be useful for the business over time (who of course still have to take the remaining uncertainty into account).
There is a reason the agile manifesto starts with the line I quoted. The number one mistake made is thinking that some tool or process will let them crank out code steadily though inefficiently with developers of unknown ability. But if you dont have those individuals interacting well there is no tool or process that can save you.
> The number one mistake made is thinking that some tool or process will let them crank out code steadily though inefficiently with developers of unknown ability.
Here’s where I disagree and would say that a well-functioning process certainly can help with that, albeit not perfectly, of course. And that is by aiding the invididuals involved in interacting well.
Perhaps you're working with a self selecting group of Americans.
As a US based developer with almost 20 years of experience across four cities and (as a consultant) many different corporate cultures, I've never met a single person who consistently works 10+ hour days, or more than 5 days per week.
That's a bold claim. How well do you know all your coworkers schedule?
As somehow who has worked for a shorter period of time, I've met dozens of such folk, many of which I have provided support for on weekends or odd times at night.
In either case, anecdotes are not adding much to the discussion.
I’ve always felt scrum adds value for new teams who haven’t worked together or on greenfield projects in a space the team hasn’t worked before. That’s when the standups identity impediments. That’s when retrospectives uncover process or people issues. Once the team hits a stride it’s time for the training wheels to come off and then it’s just a Kanban board.