191–200 of 452 posts
Earlier quoted context omitted.
It's amazing how infantilized this industry has become during my short 10 year career. I'm so thankful I switched to product and don't have to deal with this BS anymore.
... that's usually the people that try to bring this stuff in...
Earlier quoted context omitted.
> there's a good chance one of them knows something the other does not Or that the assignment of points is arbitrary and imprecise and that different people have different ways of making up numbers.
Everyone is correct in this thread. The stimulation of discussion is useful, and numbers are arbitrary. Instead of worrying about 5 vs 8 though, the team should be discussing relative difficulty: is story B easier/more difficult/complex than story A? And then ranking stories based on the relative difficulty of each other. Story points can then be derived based on that ranking, if the team chooses. They're useful for…
Earlier quoted context omitted.
Judging by the number of SAFe consultants (complete with that video of a guy drawing comic-book style diagrams about spotify, cute the first time but infuriating after the 10th) I'd have to say that if our SAFe was bastardised maybe SAFe itself is a bastard
I know many companies running SAFe on the east coast and it’s generally an improvement across the board from everybody I talk to. The only problems I’ve seen are from 2 camps: the people who don’t want to have to plan anything and the people who want everything that is planned to be 100% accurate and not a best guess. Either of these two groups will cause problems to a process like this with the latter usually being…
how dysfunctional must an organisation be for that to be an improvement? And in what way is that agile?
The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.…
Companies that implement agile to the letter typically treat their developers like consultants. You're treated as a mindless drone that is supposed to work on tasks that were predefined for you. You might as well be outsourced.
I found that kanban-style works better imo. A prioritized backlog where you pick the most important task to get done makes for a more relaxed and friendly environment, compared to an environment with a rigid deadline every two weeks that everyone sprints towards. As long as there's progressed made towards the most important items, everybody is typically happy.
Agile has mostly been a disaster IMO.. I've worked at big public companies and 2-3 startups during it's run. It works to come up with a "MVP for 1.0 and then it starts dragging everything down because it encourages tech debt.
My experience has always been the successful companies/teams were tongue in cheek telling everyone they were Agile when agile was popular while simultaneously trying to ignore Agile as much as they can because it was mostly ceremony and downsides once a product gets anywhere near mature. There was a lot of "we're agile with a lower case a" at places that could tell the Emperor's new clothes were suspicious.
Some of the old processes have been slowly creeping back in, and we're kind of at the point now where teams no longer need to feel like they have to advertise saying they're scrum/agile to appear competent. But I think you either need some older managers or something else to figure out what to do next and how to bring back the good parts of older process methodologies because it feels like theirs a vacuum.
The relationships between teams and PM have changed so much. Agile elevated PM a huge amount but as Agile moved on PM seemed to abdicate all responsibility to do their part in the whole agile process, and now you're left with a bunch of extra PM just getting in the way.
Agile without developers being included in estimates was one of the worst things.. non-technical PMs constantly shooting down estimates with "No, that is easy" is the worst. But Agile to me always seemed to be about management being able to absolve itself of all responsibility for not being able to figure out what to build or how to build it and to always be able to blame the engineers.
As we go forward teams need to look back at the past and what worked before Agile, not just make something new up out of whole cloth.
One agile team I worked on which probably was the strictest essentially pivoted the entire product to something else 3x because PM never had a clue what to build that would actually sell.
The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.…
A "scrum course" is to Scrum what a code boot camp is to programming. You're going to learn basics but you won't have the depth of knowledge to handle complexity in any form, nor how to answer questions about Scrum that inevitably are asked by leadership. There's a reason the Scrum leader (or master) role exists. It's supposed to be the person who has a depth of knowledge that goes beyond a simple "scrum course" and…
Earlier quoted context omitted.
The problem with any system is that people try to enforce it, military style. In my previous job, we did scrum, but not too strict. We had two week cycles, not-too-strict deadlines (most of the time) etc. If I finished my task early, I was free to pick up tasks from the planned list, without having to get permission from my manager. We also didn't agonize over story points, retrospective etc. We did it light hearted…
" I realized that it all comes down to "metrics" - end of every sprint, my manager has to present it to his bosses". I wonder how widespread this is.. Certainly that's exactly what I experienced at a previous workplace, and worse than that, people's performance was judged on whether they'd done exactly the "right" stories in a 2 week sprint. Rather than thinking about developing software, people were working out how…
I work in an environment that had no project management tools or methods being used other than emails and I've finally gotten buy in on Kanban and I want to make sure I guide my team properly.
As soon as you scale scrum to organization wide, you get inter team communication challenges for which Scrum has no clear solutions (because its a team methodology and not company methodology). Once you have multiple teams that need to align their plannings to get stuff done, inter team dependencies become a bottleneck. Add a few external teams to the mix and you get a perfect storm of conflicting interests, miscommunication, politics, etc.
Having a lot of dependencies between scrum teams also means you get a lot of decision making lag. Scrum teams have two issues: they work in sprints with some fixed length and you can't introduce new work during a sprint. If either is not true, you are not doing Scrum. When you have a graph of interdependent scrum teams, the lag you build up to get anything done is basically proportional to the path length through the graph. The bigger the org chart, the slower things get and it adds up quickly. The longer the path, the more planning and implementation sprints are involved in each team along the path and the more chance there is for things to get lost in translation. Beyond 3 vertices, the whole thing starts looking like a very chaotic waterfall style process where it takes months/years to even agree to do a thing.
I speak from experience. The most dysfunctional thing I've seen on this front was Nokia flying in teams from three continents to have a bi-monthly sprint planning about 12 years ago. That worked just about as well as you can imagine (i.e. not at all). You needed to get your requirements scheduled 3-4 months in advance to stand a chance in hell of anything happening under 6 months. I'm talking critical stuff getting de-prioritized because one or more teams involved got other priorities imposed on them and thus had to say no. One of two things happens in such organization (usually both): 1) things get escalated to VP level management, a lot, and there is a lot of politics with lots of egos clashing. 2) teams eliminate dependencies to each other to speed things up (i.e. they reinvent wheels they could have reused just so they don't have to deal with each other). Both are bad for productivity and cost.
The way out is to bypass middle management, ignore the process (on both sides) and establish direct lines of communication with engineers in different teams. Once you have that, pragmatic decision making can actually happen. At this scale, middle management should just not get involved with day to day engineering decisions and instead enable the day to day interactions and smooth out any inter-organizational bottlenecks.
Most of the big companies mentioned in the article are not great at this either. E.g. the reason Google has so many chat tools is because they have teams working against each other rather than with each other.
The thing about Scrum is the observations and principles make sense, but then to sell it as a course they've turned it into very specific prescriptions. I went on a scrum course and the takeaway was basically that feedback is a big deal, and you should try to get some repeatedly and quickly. It's also common sense that you should have tasks written down somewhere, and that some of them are more important than others.…
The Sprint gives a defined time period during which the team is allowed to work uninterrupted by these kinds of requests, with the updates, feedback, change requests etc. taking place at the Sprint boundaries.
Earlier quoted context omitted.
That's a long time from pr to release.
I think the biggest misunderstanding that always occurs when talking about Scrum and/or Agile is when people from radically different industries meet. From the perspective of my previous team, 1-3 days from PR to prod would be indeed quite long. For such a team, "two weeks per sprint" can seem like an eternity and will only slow things down. On the other hand, one of my best friends works for the largest insurer in t…
1 day doesn't seem too bad, often times it can be 2-6 hours. It really depends on what lines up and how big the PR is.
