Reminds me of this goto conference talk from one of the original Agile developers "pragmatic" Dave Thomas.
Speaks a lot bout what agile truly is and how scrum is a very large mismatch.
Scrum is fragile, not Agile
201–210 of 329 posts
Re: Scrum is fragile, not Agile
#202The best place I've worked at as a developer essentially had no process. It's also the place I really saw the benefits of having good managers (or a project manager, but here the manager took this role).
Essentially the "process" was:
- Someone gets an idea to do something, e.g. PMs wants to add a feature.
- The manager (maybe with the help of a dev) figures out which teams need to be involved (e.g. dependencies).
- Get a very rough estimate from developer. Are we talking a few days, a few weeks or a few months?
- Manager, PM and other teams get together to figure out priorities, schedules and who's likely to be working on it.
- Based on some discussions, areas of expertise etc, some number of devs gets assigned to work on this feature.
From here the devs know what they're trying to accomplish, what the constraints are and who to go to for questions (PM, design etc). They also know who else from other teams they're collaborating with and they just figure out amongst themselves how to get things done. They'll keep their managers and the PM updated on progress and any blockers.
Every once in a while manager etc have to step in. For example if some big that was previous unknown came up, there is a big risk, priorities need to be adjusted etc. But for the most part things just worked really smoothly.
Sometimes we need to give estimates and really hit it (legal or security issues, big marketing launch etc), but for the most part we were trusted to be doing things as quickly and efficiently as possible. So none of the commits, sprints and burn down charts BS. It's not hard to gauge develop's productivity based on output anyways. If there was something slowing the team down, we communicated the need to the manager and PM, and we worked on fixing it.
So for me, if you have good competent people that communicate well, you don't really need much process.
Re: Scrum is fragile, not Agile
#203At 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…
> Daily standup 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.
> Create tickets for debt, put them on the backlog.
That will risk making a huge technical debt section in the backlog that will find it hard to get priority. It's better to condition new features/bugfixes on the cleanup that caused them. "I can add this feature in 1 day but will need 4 days to clean it up. So my estimate is a week." I constantly nag developers to do this when they find that they are pressed for time and want to make a hack.
-"I'm nearly done but I can't find a nice way of doing this because of an existing code smell so I'm considering adding another smell"
-"Did you ever find that this was NOT the case?"
-"No..."
-"So do you always double or triple your estimates so you know you can comfortably refactor"
-"No..."
I think this is a disease of Scrum. Too short estimates exist because developers pat themselves on the back for finishing things quickly.
Re: Scrum is fragile, not Agile
#204Earlier quoted context omitted.
> Scrum is iterated waterfall. No, it isn't. Iterated waterfall is at least as old as the first paper discussing waterfall, but while scrum mandates interations, it doesn't mandate much about how work is done in the iterations, and specifically does not mandate the process steps associated with waterfall; further, it emphatically rejects the role separations and handoffs associated with waterfall during the iteration…
What percentage of Scrum teams do you believe are "properly cross-functional and self-organizing"? And could you point me to examples of people losing their Scrum certifications for not living up to that standard?
This is the great con of scrum certification — you can always point to some team and say “well that’s not the official version of scrum”
Re: Scrum is fragile, not Agile
#205Earlier 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…
DHH has a nice methodology that works with fixed deadlines: his basic rule is that features can be dropped/simplified, but deadlines must be met.
https://www.amazon.com/Doesnt-Have-Be-Crazy-Work/dp/00628747...
Re: Scrum is fragile, not Agile
#206He'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…
There are in fact two kinds of Scrum (or rather, Scrum implementations), both of them compatible with the Scrum guide: ‘Left to Right’ Scrum (backlog-driven, implementation-focussed) and ‘Right to Left’ Scrum (goal-oriented, iterative).
Unfortunately Scrum is too often explained and implemented that first way, leading to the anti-Agile feedback we see on HN with some regularity. The second way is much more compatible with complementary tools such as Lean Startup and Kanban and I wonder if this (to me very welcome) non-exclusivity explains why it is less talked about.
[1] https://blog.agendashift.com/2018/07/04/righttoleft-works-fo...
Re: Scrum is fragile, not Agile
#207At 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…
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.…
Thank you for giving me a really good laugh.
Re: Scrum is fragile, not Agile
#208The best place I've worked at as a developer essentially had no process. It's also the place I really saw the benefits of having good managers (or a project manager, but here the manager took this role). Essentially the "process" was: - Someone gets an idea to do something, e.g. PMs wants to add a feature. - The manager (maybe with the help of a dev) figures out which teams need to be involved (e.g. dependencies). -…
I think the challenge with having no process is this: You have to rely on great chemistry and raw talent.
Look at Spotifys videos on their process. Every team is self-driving, because everyone knows how to do stuff. If you work at a company where there is no process, and not every is able to complete the whole task from A-Z, you end up with deadends and people who get stuck. If the culture doesn't encourage knowledgesharing, people end up making crappy solutions.
Re: Scrum is fragile, not Agile
#209The best place I've worked at as a developer essentially had no process. It's also the place I really saw the benefits of having good managers (or a project manager, but here the manager took this role). Essentially the "process" was: - Someone gets an idea to do something, e.g. PMs wants to add a feature. - The manager (maybe with the help of a dev) figures out which teams need to be involved (e.g. dependencies). -…
I think the above can simply be summarised as "real managing and communication".
As opposed to trying to create a couple of metrics because you don't really understand what people around you are doing.
Re: Scrum is fragile, not Agile
#210The best place I've worked at as a developer essentially had no process. It's also the place I really saw the benefits of having good managers (or a project manager, but here the manager took this role). Essentially the "process" was: - Someone gets an idea to do something, e.g. PMs wants to add a feature. - The manager (maybe with the help of a dev) figures out which teams need to be involved (e.g. dependencies). -…
But how did you ensure that you udnerstood the requirements if you were potentially just left to it for a few months?
At the end was there ever an instance of the client not using what you produced because it wasnt what they wanted?