Your company isn't doing Scrum at all. Your management is only using agile vocabulary and that's where the parallels end. And that's how Scrum gets a bad name.
You may be right in this case, but is there any discipline more rife with no-true-Scotsman rejoinders in its defense?
Well I don't know any other disciplines where so many people are implementing an idea so badly :-)
If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…
You haven't seen cargo cult until you've worked in an organisation with a pmo, and tranditional project management. I had to literally write a 5 page business case for relatively small features that takes more than 5 days. You then had to get it approved by the pmo board. These people have no product management skills either. Once it's a approved I have to write a full plan and schedule. Companies like this exist. Th…
I've seen 50-page project specs written before the dev team even new there was a new project. But PMO board. Ouch.
At the other extreme, you have your process-adverse adhocracy where your brilliant new lead developer unilaterally decides the first step in fixing the latest issue with your existing CRUD application written in PHP is to write a new Node framework.
Meanwhile, junior developers are getting bombarded directly by anyone in the organization who encounters a problem while using their keyboard.
Companies like this exist. Maybe not quite this extreme. But I've encountered a few variations on this theme and they've given me a deeper appreciation for agile concepts and terminology.
I love the discussion happening here. I am into projects which "follow agile model" more than last 5 years, however every time I bring up such questions to folks who are die hard fan of these buzz words (mostly non-engineers), I am threatened to be sent to days long Agile/SAFe training again and looked down upon blaming I have "Old school waterfall mentality". I am not saying Agile does not have any value at all. I t…
> Even if engineers believe do not believe its going too fast (superficial review, lack of manual testing) If the engineers are speaking up and are actively ignored, then the business's feedback loop is broken. The things in the agile manifesto need buy in beyond the people writing code. > scrum master end up make it happen as his job is to make sure "sprint commitments" are met The whole idea of using the word "agil…
I don't think Scrum should be judged on how well it can perform but how well it actually performs. If 9 organizations out of 10 can't succeed in applying it, that's certainly a bad evaluation of Scrum even if technically Scrum was never properly applied in those organizations.
Where I work now they have attached too much overhead per story. Time tracking, statuses in jira, separate confluence page with stringent rules about the content etc. So we now make huge stories in order to actually get to spend some time implementing stuff.
I imagine when something about the project changes, it takes a really long time to rewrite all those stories? Or you end up never re-assessing because it takes too long.
We often end up reusing the stories for completely different stuff, as they then have already been approved so we can skip some of the boilerplate, haha.
If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…
You haven't seen cargo cult until you've worked in an organisation with a pmo, and tranditional project management. I had to literally write a 5 page business case for relatively small features that takes more than 5 days. You then had to get it approved by the pmo board. These people have no product management skills either. Once it's a approved I have to write a full plan and schedule. Companies like this exist. Th…
This can actually be very useful as it insulates your dev team from some VP wandering across and demanding a pet feature be implemented. The VP has to negotiate the PMO board first
If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…
"scrum master" is the one that really grinds my gears. Ive pretty much stopped doing all the jira nonsense and let my productivity speak for itself. I've been left alone about it.
Others here have more thoughtful opinions on the whole thing. I'm just kind of annoyed about it all without the energy to try to formize what's wrong and why. Just let me engineer.
Your company isn't doing Scrum at all. Your management is only using agile vocabulary and that's where the parallels end. And that's how Scrum gets a bad name.
This is the inevitable and unwinnable argument in any thread that dares to question the value of Scrum.
Because it's a version of the No True Scotsman fallacy. You're not doing "true" agile, they would say.
Has anyone had good success with enterprise level projects managed in jira? Background: each story has deliverable value to the stakeholder/ Ask: Download file from vendor, process file with error and success counts, save results in X datastore, email report with stats to specified DL...
Jira is just a ticketing system with a lot of fancy (and optional) features built on-top of it. Or are you asking specifically about the Jira Agile feature?
If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc. These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done. Please, do not point me at agile manifesto. To me agile…
I've found value in adopting bits and pieces. We have a small team (2 developers, sometimes more) and we're balancing bug fixes/customer needs/putting out fires/new development. Some guidance about where we're going and what we're walking on keeps us from focusing on the wrong things, but at the same time, when there's 2 developers you have to minimize overhead. I use a backlog and "sprints" (just a range of dates really). I assign points to have a bit of a clue (since I have to be able to answer what's on my plate and give some guidance as to when things may be completed). Nothing is sacrosanct: bugs get points the same as new development, since to the business it's all revenue blockers. A sprint is never carved in stone; any thing can be put in at any time, and priorities can be shifted, as they necessarily must. I don't do planning poker, standups, or retros ... daily communication via Slack is sufficient. We have no made up jobs like "scrum master". To me it's just a framework, in the same way that TDD or MVC are. You adopt pieces that help you get shit done, and ignore the pieces that get in the way of getting shit done.
With a lot of agile stuff I feel like you tend to end up with a result like a PT cruiser car. Some years ago I rented one and they had done everything right: Interesting design, cool features on the inside, analog clock on the dashboard and everything else. They had checked off all user stories of the car. But the end result was a crappy car. A lot of features were implemented in a subpar way. Nothing really fit and…
It's akin to technical debt, maybe call it Agile Feature Debt. You implement a feature, it's done, all obvious bugs are fixed. But now that you have finished it you've gained additional knowledge from actually using it. And you realize the way it was designed or implemented isn't optimal, in fact sometimes you realize the way it works is dead wrong, and makes the product less usable. Too late. It matches the spec. It…
A significant part of the agile process is that meeting the spec isn't the goal, being accepted by the customer is. Your description sounds like there were no sprint reviews to get customer feedback, or it was ignored. So you're arguing that a significant problem with agile is that if you skip a fundamental piece, it results in bad outcomes?