Scrum is very clear on this. The PO is in charge of the product backlog. The PO and PO only. If the business has some internal alignment she needs to go through then fine, but the development team doesn't have to care about that, which is great when it works and roles are respected.
There is no mention of permission in scrum. There is no event where you discuss if people had permission to do what they did.
You might be using scrum in an organisation that is otherwise overly restrictive or has build it's own processes around how to seek permission prior to implementation but that has nothing to do with scrum.
What did you do yesterday? (Also their next question is somewhere arround why didn't you finish it)
What are you doing today? (That sounds like scope creep)
Are there any blockers? (Let me give you my unsolicited advice)
If you're in a toxic team, maybe. I have found it to be the minimal useful script for daily updates because it 1) quickly updates the team on changes, 2) quickly heads off duplicated work and misunderstandings, and 3) provides a fast channel to get someone help.
I am not really seeing the problem here, nor do I agree with the premise that scrum turns X developer into Y developer. Your success as a developer is primarily driven by your desire to succeed, but also by a combination of the team, project, and company culture. Scrum is not at fault here, because bad management, lazy team members, and a toxic work environment can make any worker in any discipline complacent, no matter which system is used. I’ve worked for 20 years in this industry and have seen various management and development methodologies used, and my conclusion is that what matters most is the attitudes of the people themselves. If you have even one toxic coworker or even worse, a toxic leader, it can change the morale of an entire team and possibly even put an entire project at risk. That’s what can turn a great developer into an average one. If you have below-average developers, scrum will do nothing to actually make them more motivated; they will probably remain average, despite appearances that they are moving tickets quickly.
Like any other system, scrum can be abused and twisted into something it was never meant to be. A project I worked on had daily scrum-style standups as well as daily, weekly, and monthly status reports; We also had Jira and our boards were closely scrutinized by every level of management and the customer. We happened to use scrum, but you couldn’t look at this and say scrum was at fault for such duplication of information and ridiculous reporting requirements.
Poor scrum. It gets so maligned. If you have a high functioning, well gelled team with well developed communication habits and rituals, you don't need scrum. But, guess what, those are few and far between, and scrum is an excellent starting point.
Whenever I see a complaint it's usually because someone involved has violated some part of scrum. It's run by the developers. They set what they're planning to work on. No one else should be talking in scrum meetings, and certainly not making decisions based on scrum meetings. It's totally fair to evict everyone else.
Take the hard problems thing. You can tackle hard problems. Saying, "I'm going to try working out this prototype idea and do a literature review of this topic" is perfectly reasonable as a plan for a week or two.
Where I work, we can choose what we work on, as long as it's one of the backlog tickets the product owner wants done for the next release.
The way they are formulated means there is very little room for solving hard problems (of the type that could result in fifty tickets not being necessary anymore), let alone making prototypes for things if they aren't guaranteed to releasable results for any of the tickets.
It's a shame that the consultants took scrum and destroyed it. Here is the truth about scrum. Scrum is a radical framework to get rid of management and therefore micromanagement. Scrum is meant to empower creators by destroying all obstacles that get in the way of creating great work together. Here is a great source to start. http://scrumbook.org/
Show and tell is pretty fucking gay, and that's why scrum is dogshit. Just tell me what to do, and I'll fucking do it.
When you trot me out like a show pony, or force me to share, like this is group therapy or something, it ruins my day.
Every fucking day.
The emotional labor of collecting my thoughts for a 15 minute public speaking engagement, particularly on days, when the project was planned too poorly for me to have anything worth sharing for days, or even weeks on end, means that I hate myself for the lies and theater and hoops I must jump through, simply to seem like a good sport.
Sorry, but you just have to portion out work better, which means actually having a clue about what you're going to try and do before you do it.
Most teams and projects are not under the impression that there is blue sky investigation required to explore certain subject matter and areas of interest. Feature factory assembly lines with cookie cutter operations get impatient, when confronted with stalls due to clueless planning. Whoops!
So, whatever the fuck. Who cares. Stick your hand up my ass so that I parrot buzzwords like a good little puppet, and see what you get for it. Somehow, most teams lack the ability to write down what they want. You get these one-liner task assignments: do the thing. And then expect no blockage or derailments? Okay, have fun with that.
Is it just me, or is it the case that in discussions about Scrum, most of the responses are “then you’re not doing it right”, “no true Scotsman”-style?
Yes, but then most organisations just do daily standups without any clear goal, use Jira and have two-weekly planning meetings and then say they're doing Scrum.
I once heard that described as "the non-falsifiablility of religion surfacing".
You might have noticed that the answer is never "maybe your situation calls for trying these small tweaks to the vanilla scrum process..." even though Scrum claims to be about retrospectives and continuous process improvement.
21 comments
[ 2.5 ms ] story [ 65.0 ms ] threadHow very agile.
You might be using scrum in an organisation that is otherwise overly restrictive or has build it's own processes around how to seek permission prior to implementation but that has nothing to do with scrum.
Then you have nothing to worry about, you don't have any great developers.
Like any other system, scrum can be abused and twisted into something it was never meant to be. A project I worked on had daily scrum-style standups as well as daily, weekly, and monthly status reports; We also had Jira and our boards were closely scrutinized by every level of management and the customer. We happened to use scrum, but you couldn’t look at this and say scrum was at fault for such duplication of information and ridiculous reporting requirements.
Whenever I see a complaint it's usually because someone involved has violated some part of scrum. It's run by the developers. They set what they're planning to work on. No one else should be talking in scrum meetings, and certainly not making decisions based on scrum meetings. It's totally fair to evict everyone else.
Take the hard problems thing. You can tackle hard problems. Saying, "I'm going to try working out this prototype idea and do a literature review of this topic" is perfectly reasonable as a plan for a week or two.
The way they are formulated means there is very little room for solving hard problems (of the type that could result in fifty tickets not being necessary anymore), let alone making prototypes for things if they aren't guaranteed to releasable results for any of the tickets.
So I don’t think any methodology which involves getting rid of management will be successful, or get widely implemented unaltered.
When you trot me out like a show pony, or force me to share, like this is group therapy or something, it ruins my day.
Every fucking day.
The emotional labor of collecting my thoughts for a 15 minute public speaking engagement, particularly on days, when the project was planned too poorly for me to have anything worth sharing for days, or even weeks on end, means that I hate myself for the lies and theater and hoops I must jump through, simply to seem like a good sport.
Sorry, but you just have to portion out work better, which means actually having a clue about what you're going to try and do before you do it.
Most teams and projects are not under the impression that there is blue sky investigation required to explore certain subject matter and areas of interest. Feature factory assembly lines with cookie cutter operations get impatient, when confronted with stalls due to clueless planning. Whoops!
So, whatever the fuck. Who cares. Stick your hand up my ass so that I parrot buzzwords like a good little puppet, and see what you get for it. Somehow, most teams lack the ability to write down what they want. You get these one-liner task assignments: do the thing. And then expect no blockage or derailments? Okay, have fun with that.
You might have noticed that the answer is never "maybe your situation calls for trying these small tweaks to the vanilla scrum process..." even though Scrum claims to be about retrospectives and continuous process improvement.