151–160 of 329 posts
Managers, not understanding the difference between latency (how long each task takes) and throughput (how much work is getting done in total), always try to optimize for latency. The predictable result: throughput goes to hell, and then latency goes with it. People who actually write software understand that you have to optimize for throughput first. Not to worry: latency won't be forgotten! But a primary focus on th…
At the company I work at, we have the following scrum anti-patterns. I wish I knew, whether we could "do scrum right" or just move onto something simpler (fta; priority queue) * Daily standup, nobody wants to be at. We have multiple teams arrive, with roughly 20 people in a small room. Some people stand, some people sit. Sometimes the front-end team goes, sometimes the back-end team goes. Its limited to 15 minutes, s…
Change them so that people talk about what is blocked then.
> Scrum master
Tricky, like anyone who doesn't want to adapt.
> Technical debt
Create tickets for debt, put them on the backlog.
> Poor product owners
Tricky.
He's not wrong. Having been involved in the Agile movement since before the term Agile was coined, I think of Scrum as the least interesting of Agile processes, but also the most successful in terms of adoption. I used to think that was a contradiction. Now I think it's almost inevitable. I wrote more about it elsewhere [1], but the basic deal is that most companies have other priorities than being effective, so the…
Scrum is badly misunderstood and maybe that's a failing in and of itself but it's really a victim of the developers who sold it as a magical process. Scrum simply can't be implemented as a purely developer process. The backlog exists as a rolling contract between dev and product owners and sponsors. The most common failure I see is when project leadership agrees to a fixed scope and timeline then tries to execute in…
Earlier quoted context omitted.
> Daily standup I have never worked at a company where this actually goes right and could not be replaced by [insert ticketing system here]. We use Basecamp to do daily check-ins on a very high priority issue, if we have one, which we usually don't.
Managers are the only people that like daily standups, so far as I can tell. I've never figured out why you couldn't just do it over slack or equivalent. It's massively inefficient to get everyone to meet up in the morning.
From the scrum guide... "The Daily Scrum is a 15-minute time-boxed event for the Development Team."
It is the team's event, if there are other people there it should be at their request. The guide goes on to say that.. "If others are present, the Scrum Master ensures that they do not disrupt the meeting."
I am curious how much process research is being done as an industry. With billions at stake, it seems like I would run across more studies where teams were paid to produce the same software independently. But virtually none of the methodologies I read are backed by much rigorous experimentation. Maybe it exists and I am just not reading the correct articles.
[1] https://pdfs.semanticscholar.org/85d0/00404206914501d26e0bb4...
[2] https://www.researchgate.net/publication/261047173_Agile_and...
Earlier quoted context omitted.
The way I decided to play the game was like this, "I won't be attending the Daily Standups anymore as I don't think they add value and do subtract value." The project mgmt response was, "Attendance at standups is mandatory." Regardless, I didn't go to anymore standups and when I got flack for that, I stopped going to the office all together. When I got flack for that, I stopped working all together. Then I got fired.…
I got criticized for zoning out at scrum meetings. So I watched what the managers do. They show up for the first few minutes, look alert, then leave as if in a hurry. I started doing the same thing, and never had a problem again.
Earlier quoted context omitted.
Managers are the only people that like daily standups, so far as I can tell. I've never figured out why you couldn't just do it over slack or equivalent. It's massively inefficient to get everyone to meet up in the morning.
Why are your managers attending stand up? The Daily Scrum is the team's meeting. I swear Scrum is only fragile because no one reads the bloody book, or if they do they skim it or ignore it. From the scrum guide... "The Daily Scrum is a 15-minute time-boxed event for the Development Team." It is the team's event, if there are other people there it should be at their request. The guide goes on to say that.. "If others…
Stand-ups and all the process attendant appears to be universally imposed from on high as a micromanagement technique, or because they were sold the idea as some kind of silver bullet by a talk or a snake-oil consultant.
Reading all the comments out there, there is some atrocious stuff people call Scrum. I'm not even a huge Scrum fan, but it folks seem to criticize what people do in the name of Scrum instead of what is actually in the process. The TLDR of Scrum is simple: (product) management gets to set the priority of things every 2 or 3 weeks. After that, we see what got done and check to see if the priorities are still the same.…
Of all the people complaining about Scrum it doesn't sound like any of them have read the Scrum Guide. Symptoms of Scrum are not managers pressuring people at stand ups, squeezing 4 weeks of work into 2 and having a "team" of 20 people. These are symptoms of poor leadership.
I've worked on more than 10 different Scrum teams, and have seen it done well exactly once. When it was good, it was very good. But we spent one entire workday (7 hours) on each sprint follow-up meeting, and then another entire workday planning the next sprint. That is what it took to write the stories, break them down into one-point pieces, prioritize with the PO, pass the stories out to the devs, etc. Most places j…
I'm on a team that started doing Scrum a few months ago, and we're still figuring it out. To be clear: are you saying that the one team that did Scrum well did so because they spent more time on the process? Reading what you wrote, spending two full days every two weeks to plan sounds, well, terribly dragged out. Does it feel like the time was well spent, or was it a slog?
During the project, it felt like a bit of a waste. We were spending a full 10% of our time on project management. However, looking back, I see that a) it seems to match up with other's experience, and b) it's pretty much the same amount of overhead for project management that the project would have had using any methodology.
At least with the 1-2 days every 2 weeks everyone sees it and it's something you can get better at. I'll take that over magical GANTT charts any day.
Earlier quoted context omitted.
Scrum is badly misunderstood and maybe that's a failing in and of itself but it's really a victim of the developers who sold it as a magical process. Scrum simply can't be implemented as a purely developer process. The backlog exists as a rolling contract between dev and product owners and sponsors. The most common failure I see is when project leadership agrees to a fixed scope and timeline then tries to execute in…
Have you seen any methodology work consistently when dealing with fixed deadlines? The reality when dealing with large contracts, as you mention, is that there are almost always timetables with expectations. This poses an inherant problem due to the unreliability of estimates, so either quality or features must be sacrificed if the timeline is in jeopardy. My only experience in such an environment was using some hybr…
Developing new aircraft, building a new ship, building a custom-designed bridge (most of them are) are processes that often run out of time and / or budget.
If you want predictability, you want repeatability. But in software all reliably repeatable parts become automated away.