151–160 of 223 posts
I interviewed a long time ago at a med tech company in Boston where Jeff Sutherland, one of the inventors of scrum, was the CTO (I believe). I had recently been through scrum master training at my current job and was quite keen to see how scrum was applied in the place where the guy who invented it was working. I asked my first interviewer how they used scrum on their team and his answer was that they didn't use scru…
Earlier quoted context omitted.
I remember we had a discussion about 10x developers a while ago and how some developers are perceived as moody divas. My guess would be that the 10x-ers have are independent enough from any given employer that they can reject Scrum even if everyone else has to follow it. And later on, their ability to work on their own terms is what then makes them 10x more productive than the poor scrummers.
I am definitely a "moody diva", I think because daily standup in particular forces me to admit more failures than I would have to otherwise (you need to fail before you succeed). And it's ultimately pointless and more stressing for everyone, because lot of these failures get resolved the next day. In some sense, standup is a nocebo, a mood killer for me. I am there, in the morning, ready for work, my mind firing up,…
They do have their benefits though, especially when well run. A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.
I suppose that most of those things could just be done as a slack message. Sometimes I feel like a meeting helps ideas flow better though. There's been occasions where having an actual verbal conversation with the team has yielded better results than a slack conversation would've.
Either way, I've never had a huge issue with them, as long as standup is the start of my working day and not like 10 AM or something where I'm going to get interrupted.
Earlier quoted context omitted.
Actually the brilliant loner should be the norm (to have one), not the exception. If you believe in the 20:80 rule, that 20% of the people to 80% of the work. This rule doesnt sound so bad but actually (lets take these numbers as strict and not as a probability distribution). It means your top perfomer are 16 times more productive than the lower performers. Lets say you have a team of 10 people doing 100 work units.…
In my experience having a brilliant loner on the team increases the amount of work the team needs to do by more than they contribute. Also, very often , what they contribute is clever solutions to problems that didn't need clever solutions. The few teams when I've had that sort of person on my team productivity has gone down, not up. Regarding the point you make about 20% of the people doing 80% of the work, that's h…
Give me a team of superstars and we'll deliver a half-finished framework for solving the general class of CRUD problems one could have, along with a bad implementation of a gherkin dialect.
Earlier quoted context omitted.
I've also seen it fail the other way where the Skunkworks becomes the preserve of "high achievers" not producing a lot that's useful. Almost every 'Office of the CTO' I've seen has suffered that failure mode. Lot's of things get built but none are more than fluffy experiments and there's no path to actually putting any of those things into production. Once in a while they'll be forced through and the production team…
Isn't that just a lack of clear goals? Skunkworks had extremely ambitious deliverables and was not a science lab, even though they helped develop a lot of new technology.
Earlier quoted context omitted.
> there are no managers in SCRUM A philosophy that hinges around some ideal of how the world should be, rather than dealing with the world as it really is, often ends up being implemented as the exact opposite of that ideal. I can think of some historical parallels...
Just don't call it SCRUM. Call it "fraud SCRUM because it sells so well" or "lipstick SCRUM so we look cool" or "didn't read SCRUM but we have meetings and sprints". SCRUM works, maybe not for everyone but this denies us a chance.
Earlier quoted context omitted.
I am definitely a "moody diva", I think because daily standup in particular forces me to admit more failures than I would have to otherwise (you need to fail before you succeed). And it's ultimately pointless and more stressing for everyone, because lot of these failures get resolved the next day. In some sense, standup is a nocebo, a mood killer for me. I am there, in the morning, ready for work, my mind firing up,…
Some standups, I feel like I'm back in primary school doing show and tell, as I get regaled with tales of whatever meeting someone had (even better when several people feel the need to bring up the meeting that literally the whole team attended), or their progress on a completely unrelated project/feature which may as well have been what they had for dinner last night, for all relevance it has to me. They do have the…
Earlier quoted context omitted.
That's an insightful concise description of "agile" experience. As an anecdote, I have an acquaintance who is a psychologist in silicon valley and he has mentioned he frequently works with patients suffering from mental health issues related to being subject to "agile" at work. I wish someone would do a proper study on this topic. Personally, agile hasn't driven me to depression but it has made me target roles that a…
I found that testers in particular find agile off putting and some avoid working at such companies if they can. I am not sure why testers specifically end up disliking that. I think that agile ignores human psychology. First, in management theory, intrising motivation happen when one has autonomy, mastery and purpose. Imo, plus accountability. Agile removes that from individual, but has some rhetoric that places it o…
What i don’t like most about scrum is the sprints. Doesn’t matter if it’s one or two weeks long, we never have a successful sprint, the velocity chart looks like random numbers, and we spend hours on debating what the story points really mean. Sprints are artificial deadlines that don’t really make any sense, developers don’t care, business people don’t care. A project i could complete in a month will take at least t…
Our sprint planning sessions were a FULL DAY, yes, an entire 8 hours of planning. Because our scrum master wanted a detailed plan of what every engineer would be working on, on every day of the week.
I still remember a certain even where we were forced to adjust our story points, so that we could make a detail a month in the future. Yes, our “agile” team, had a hard deadline that we had to try and make work. This was the business decided that we’ll launch in a month, so now we’ll use our agile methodology to somehow make it magically work. During a full day session to plan for this, I suggested we should drop our scrum board and instead revert to kanban. The scrum master threw me a dirty look and told the business about this, pretty sure that’s why I was moved to another team.
Earlier quoted context omitted.
Just don't call it SCRUM. Call it "fraud SCRUM because it sells so well" or "lipstick SCRUM so we look cool" or "didn't read SCRUM but we have meetings and sprints". SCRUM works, maybe not for everyone but this denies us a chance.
No True Scrum again...
So often it is PM who destroys project. I've seen good PMs. Two. Great guys. Great managers protects project from upper management and helps to resolve teams disputes. Others... They are like third wheel - developers like to build, business knows what to build, managers - exercise control.
Earlier quoted context omitted.
I agree with this point of view. In my opinion, one of the greatest fallacy of Scrum and some agile methods is: "Another note on breaking down tasks into chunks" This is the management trick of "divide and conquer". But for real good dev, that is not a good development process. Imagine you are an experienced dev and you need to refactor a 20 files low level code to change the way errors are returned: If you were in a…
You know you've described the opposite of agile approach, right? "management", "file by file, function by function", "exchangeable and a commodity"... at least not what agile was ten years ago. Actually the points in favor of agile were: * utilize persons strong points * reduce management * reduce burden * improve working environment
But was is used today as "agile", "agile in business", agile in real use, and especially Scrum is not what the Manifesto asked for, quite of the opposite in the end.
That is even why some of the creators of the agile manifesto backed off when they saw what it became.
In fact, at the moment a company or a people say "we will create an agile team here" (maybe with a specific process scrum/...), you know that it is failed. It should be like "we have experienced software engineers, we trust them to be autonomous and smart enough to do it how they individually want to be the most efficient/adequate. Also they have responsibility and their opinion is taken into account for business decisions"