Software quality of what is built in the scrum way seems poor as it does local optimization and doesnt focus on long term.. seems like some thing that would work for consultancies the best?
Simple Kanban seems more effective, do you feel the same way? Am I doing scrum wrong? Is scrum built to ensure that program managers / product managers have something to do?
What I've seen is that the more hardcore you are about scrum/agile, the more it works against you. It's something of an anti-pattern.
That isn't to say the entire notion of regular short meetings should be thrown out entirely, though. What seems the right balance, depending on your situation of course, is to have a quick team meeting over zoom/other two or three times per week if possible, async otherwise over slack or similar. Leave the rest of the ceremony out entirely, and use something like kanban/trello/etc for tracking specifics.
The meeting isn't at all about the kanban board/cards, it's about the team spontaneously discussing approaches/issues and helping each other out. One of those "the whole is more than the sum of its parts" things.
In practice, I think it's one of those things where you should follow the rules for a while, until you can tell where it makes sense to break them. If you half-ass the implementation, you end up doing the same things as before. If you overdo it, the process stops serving you, and you start serving the process.
I do appreciate daily standups and retrospectives, but only if they're well-run. Otherwise people attend it like the Simpsons attend mass.
Personally, I prefer Kanban for its lack of arbitrary divisions and estimations. It doesn't encourage basing solid deadlines on guesstimations, and allows for on-the-fly priority changes. It requires a lot less discipline, as your only job is to keep the backlog sorted.
> There is so much jargon and cruft around it; planning poker, story points, scrum master etc
Neither planning poker nor story points (nor even stories, which are a prerequeisite for planning points to be “story points”) are parts of Scrum. They are independent practices each with their own history, rationale, and associated bodies of knowledge that are frequently used within various development methodologies including Scrum.
> Software quality of what is built in the scrum way seems poor as it does local optimization and doesnt focus on long term.
“local optimization and doesn't focus on the long term” doesn't seem to be an inherent feature of Scrum particularly contrasted with “simple kanban”, which you suggest is the superior alternative.
> Simple Kanban seems more effective, do you feel the same way?
I think flow-based rather than increment-based methods are generally superior, and I am increasingly convinced that the Scrum Master and Product Owner roles defined in Scrum are counterproductive, demotivating, contrary to the Agile principle of collective ownership, and thus generally a bad idea, abd I think that while a daily checkup/plan update meeting is useful, I think most of the common ritualized use of the daily scrum (“did/doing/impediments”) is better served by a shared visual indicator, so, yeah, I tend to favor something more kanban-ish than Scrum (whether by that you mean Scrum-by-the-book or Scrum-as-commonly practiced).
> Is scrum built to ensure that program managers / product managers have something to do?
No, nor does Scrum even define roles for them. If they exist in an organization, they are outside the scope of Scrum.
However as one commenter said, it's not about quality. Big companies have to feel that sweet, sweet cash, as soon as possible, at the cost of the devs.
It was popularized as a way to micromanage developers and drive them to produce more.
I think we can argue about whether that 'more' has been quality or not, the right output or not, whether developers and other workers deserve dignity or not, etc., but I think it continues to deliver on its core goal -- tighter management control of and domination of workers, with all the benefits for management and ownership and investors that brings.
For example, a company I worked for a few months back paid a management consultant tens of thousands of pounds to help them improve the productivity of the engineering team. As a result various new ways of working were introduced, one of which was a very strict implementation of scrum.
To oversee these new ways of working several scrum masters were hired at the cost of several hundreds of thousands of pounds in salaries.
At no point during this process was the engineering team themselves consulted so of course the whole thing was a nightmare and significantly reduced our productivity as we were now spending half of our time attending unneeded scrum meetings and being chased by scrum masters. Actual problems we faced such as needing to support legacy system and the constant bug fixing of crappy code we were forced to ship were never discussed.
In my experience scrum works well as a rough guide for how to manage a modern software team, but it rarely works when it's done bureaucratically and introduced by people higher up in the organisation who have little understanding of the actual problems faced by the engineering team. Rarely have I found scrum to be the core problem. It's usually that the people who introduce scrum care more about introducing scrum than something that works.
My experience of scrum in small companies, especially small companies with a software focus is far more positive. When companies are able to be flexible and avoid dogmatically implementing scrum it can work well, but I've certainly shared your frustration several times in my career.
No, I would have told you if there are blockers. Just because there aren’t don’t mean this is “easy”, and while I realize you need to explain to the stakeholder why it’s taking longer, neither of you are going to understand anyway, so it’s a waste of everyone’s time.
Why would I trust something like that instead of something organic?
If you are building a product with a very close partnership to the end user with a small, experienced team who share a both a common view of the world and a common definition of success then scrum can work very well. Although, ANY methodology can work well in that environment.
The further away from that ideal the less successful scrum will be. Do you have a team of mixed ability? Scrum will have trouble because you are supposed to view everyone’s opinion as equally valid (but that new grad just doesn’t know as much as the grizzled veteran and scrum doesn’t accommodate mentorship).
Are you one or two steps removed from the end user? Then you are going to have problems because scrum demands a tight feedback loop with your user so if the “product owner” needs to launch a three month “customer survey” to answer every question you have many sprints without any meaningful feedback.
The fundamental truth is you can dictate what is built, or you can dictate when you want it. You can’t do both (because any meaningful software is by definition novel).
Scrum tries to say “deliver every sprint” without being opinionated about what get’s delivered. That can work with a tight feedback loop with the end user, but invariably product managers, sales, and business strategists get involved and they all want to be able to promise Things by Dates (“we won’t hold you to the dates, honest”) and that’s where it breaks down.
All of this is before you even get into the cargo cult of points poker (the value is in identifying mismatches in shared reality, not in sizing the stories) or stand ups (which only work if you are all trying to deliver One Thing).
Finally factor in that early adopters or scrum were actively looking for alternative ways to develop software beyond the “conventional wisdom” of waterfall whereas now everyone views agile/scrum as conventional wisdom and it’s unsurprising that most people have a decidedly subpar experience.
It's so idiotic I was shocked when I first experienced it.
As a product owner, I find Scrum to be limiting. It does not empower me, it restricts me. We can't just tell a talented dev to go figure something out, we need to break it up into the right sized pieces and fit it onto a board. That does not give me "something to do", it actually burdens me with micromanagement. I just want to lay out what needs done, then let the engineers do it.
In that, you are correct - Scrum does not fulfill the main goal of product management, of building the right product. It does make the dev process more predictable. But I've never known a good product person who care more about the predictability of the dev team than they do about the quality of the product. Standard cliché here - be careful what you measure, as that it what you will improve.
So yes, Kanban is better. I can lay out details, devs can work it, and it takes the time it takes. Maybe Scrum does give better charts and graphs to our leaders. But we get things done. We research what needs researched with freedom to find the right solution... not just a solution that fit into the timebox on a Jira card.
Scrum could be a consequence of a goal it shouldn't be the goal.
However it takes a level of commitment and often breaks down if you're not active in implementing it. The standup is a perfect example - stakeholders shouldn't be part of it and it shouldn't go into strategy or deeper discussions. Everyone knows that, and understands why that's helpful, yet both of those rules are constantly violated. A good scrum master (and you need one because it's impossible to stick to the rules without someone who feels empowered to enforce them) will keep things on topic, and I remember at one company one scrum master kicking out the stake holder from the standup multiple times. At most companies the power difference is too large to do that.
The jargon and emphasis on processes makes it too easy to focus on the surface level of scrum rather than the intention behind it. If it were presented as a flexible set of processes that you can customize to your team and project I think it would be far more successful.
And when it comes to Kanban, it really depends on the project. If you're working in a factory setting (like making assets from a list) or if you have a stable product and you're adding orthogonal features, Kanban is ideal and scrum doesn't work. If you're working in a space with unclear or developing requirements and some amount of R&D then scrum is a good fit. Scrum can make large teams move quicker but everyone needs to be on board with WHY it works, instead of HOW (which is typically how it's presented).
Ultimately though there is no one-size fits all approach. What you want is as dumb a system as is possible given the complexity of the requirements and communication.
Nowhere in Scrum does it mention how to create software. This is for the team to decide. If the team is creating bad software, I struggle to see how it can be attributed to a team management framework they use, unless of course it isn't official Scrum but some bastard child of the organisation.
You are correct that Kanban is effective. But again, it is a tool that can solve problems in certain contexts. It is more suitable than scrum in some organisations, and vice versa in others.
For example, a product that has many high demanding customers who require plans months or even years in advance will find Kanban ineffective for planning. Telecoms companies are good examples of this where their customers take new software and integrate it with their own systems. They require a tight schedule.
On the other hand a bank which has a product that is only used within the company and no external stakeholders may serve better with Kanban.
There is a lot of 'scrum hating' in the comments here. It's important to remember, companies have every incentive to get effective processes that everyone likes. Bad processes means unhappy developers means more turnover. The ones who focus on bureaucracy suffer for it in the long run. Scrum is used by large companies across the world because it works. Is it perfect? Absolutely not. Is it easy to abuse? Certainly - it's flexibility is perhaps it's biggest benefit and flaw. But when it's done well, it's highly effective. Just ask anyone who works in an effective scrum environment.
1) Making good software efficiently
2) How can stakeholders get a better sense of how much work a team can do per unit of time
I don't think scrum offers anything in the first department that "Hey, don't do waterfall" doesn't. I don't think this advice needs a capital "Agile" or Scrum though. It's pretty obvious nowadays.
As for the second gaol, I don't think it offers much either beyond the advice "Hey, speak up if you encounter a blocker and think it's going to take longer." Again, I don't think that deserves a capital Agile / Scrum. Has anyone actually been on a team where you nailed down your velocity and this truly helped anyone?
I think a good process is Design <-> Iterate -> Ship, have a real quick standup to identify problems early and often and then report back to stakeholders. Just pull tickets Kanban style. Have a retrospective once a month or so.
Doesn't deserve or need to be a whole religion.
There are some basics that should be addresses though, progress visibility (issue tracker, milestones, ...), estimation by assigned developer (for responsibility), product management, shared expertise.
If you ask if scrum is good then I read it "if working in iterations with PO and regular checkups is good" and my answer is yes. But you can achieve the same with kanban or any agile workflow.
There is a lot of misconceptions about what is and what isn't scrum. Eg. the fact that all scrums I've seen come automatically with estimations is Cargo Cult to me. From my experience, problems with scrum don't really relate to scrum, but rather these Cargo Cults or "our scrum incarnation", which comes down to misunderastanding it.
Basically, Agile with capital A is ridiculous. But needs to exist in order to sell the industry behind it.