Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum is fragile, not Agile

dennisweyland.net

Post reply on HN
Print view View original

171–180 of 329 posts

Re: Scrum is fragile, not Agile

#171

Post by geofft »

mempko wrote: post #48
geofft wrote: post #28

Earlier quoted context omitted.

I'm already able to pivot every day—it's part of the autonomy inherent to me being hired as a professional. I can make decisions about my work, and ask my colleagues to make decisions about our group work, as necessary to deliver on business needs. Making a process and a specific time about how to get approval to pivot is less agile.

You ability to pivot as an individual is already limited based on your team. In fact a unilateral pivot is destructive and can inflict pain on everyone else. I'm not sure how having implicit and ad-hoc patterns of interactions is agile. Why? because you can't improve what you can't see.

I guess part of my skill as a professional is knowing how to work with my team, communicate as needed, understand whay they need to deliver business results and get them to understand what I need to deliver business results, prioritize as needed, and make sure I'm not inflicting pain on everyone else.

If you don't have that level of trust in your team members, sure, formal process makes sense. And I'm all for it if that's what's needed to deliver business results successfully. But you're then valuing processes and tools over individuals and interactions, following a plan of when and how you may respond to change over letting individuals figure it out, etc. Again, it's perfectly okay if it's not agile if it's what the business needs. But my assertion is it's not agile.

Re: Scrum is fragile, not Agile

#172

Post by spronkey »

anon1m0us wrote: post #32
brightball wrote: post #22

Earlier quoted context omitted.

Scrum won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

Waterfall was coined by a paper discussing why waterfall wasn't a good way to do software projects. You aren't wrong, either. I found Scrum to be a series of waterfalls that weren't well thought out. "Iterative Design" essentially meant, "We aren't sure what the button should do exactly, but we know we need it there and it kinda has to do this and we'll figure the rest out for the next iteration." That caused so many…

Personally I believe this is one of the major gaps in Scrum, and there is no prescripted way to solve this problem. XP's focus on technical aspects is much better in this regard, but the possibility of runaway technical debt still exists.

There are so many places where this can sneak in and become an issue, too:

- The development team can groupthink, underestimate and/or fail to account for technical debt payback in planning poker. They may estimate the cost for the new feature, but not include any time for refactoring to keep the codebase healthy

- The Scrum Master may not shield the development team from pressure to deliver coming from the product owner, which may cause the team to cut the above corners

- Codebase health may be split out from vertical stories into its own tasks that get deprioritised by the product owner

- Even if the development team identifies the need for codebase health, this may not be communicated back to the product owner in a way that makes business sense ("but we can still get this feature out the door quickly and fix the mess later, right?" - yes, once or twice, but the downside is a slowing of velocity)

- Even if the team started well with ground rules the Scrum Master is supposed to enforce surrounding technical quality, the Scrum Master may not be effective in enforcing the process - either because they lack authority or because they lack the ability or knowledge to do so

Among several others.

In your situation, the big red flag is that the team predicted the issue many months prior. The process has failed to extract that information from the team members and deliver a consensus between them and the product owner.

Though ultimately, as with any project, if the product owner has more organisational authority than the development team and chooses to exert this authority, no process will be able to save you.

Re: Scrum is fragile, not Agile

#173

Post by je42 »

keypusher wrote: post #153
tootie wrote: post #132

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…

One thing about agile is that usually companies not only set fixed deadlines but also fixed feature set; which usually means lower quality.

That in turn means technical debt; which puts future deadlines and feature sets at risk.

Since in SCRUM as a team you try to not compromise on quality the only way out of this is to push back on deadlines or feature set (or both).

So instead of blindly executing orders; the development teams can push back on deadlines.

Most of the time these are actually negotiable. Even the "hard" deadlines....

It doesnt mean the dev teams always win however they are better equipped to inform "management" about the consequence of the deadline.

Re: Scrum is fragile, not Agile

#174

Post by innocentoldguy »

brightball wrote: post #22
wpietri wrote: post #12

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 won out because it was waterfall in disguise. Commitments and sprints become terribly destructive over time.

I agree. The last "waterfall" company I worked for was Novell. In my opinion, all the Novells of the world glommed onto Scrum because it was shiny and new and allowed them to call all their bloated and unnecessary project managers "Scrum Masters" and all their wasteful status meetings "Stand-ups." It was just the same old garbage with a different name, but hey, We're Scrumming!

Re: Scrum is fragile, not Agile

#175

Post by allthecybers »

forinti wrote: post #68
xyzzy_plugh wrote: post #54

Earlier quoted context omitted.

This mirrors my experiences to a tee. The most upsetting experience in my career thus far was being belittled by an incompetent project manager. "How could it possibly take that long? How do you not know how long it will take?" The happiest times of my career have been when we're lacking a PM -- coincidentally the most successful!

Best PM I ever had dropped by every week or so to ask if we needed anything.

That's what the best ones do.

Re: Scrum is fragile, not Agile

#176

Post by hendershot »

The problem often is that scrum (or any iterative process) fails when it's not paired with good XP engineering practices. There's constant learning and change on the product side, which drives constant learning and change on the implementation side, the code needs to be constantly refactored to best handle the changes.

TDD/yagni/refactoring allows you to keep your code base nimble. I can't imagine doing an iterative process by slamming features in one after another without refactoring the code as you go to handle what "you now know", or not having good test coverage to support the changes you need to make.

Refactoring also shouldn't be something the PO is aware of, it's not a story, or a 2 month break from feature development. It's part of the job as each story is implemented. Yes, sometimes you don't notice a good way of doing something until some time passes and that area of the code becomes a bigger refactor than usual, just have to deal with it as soon as possible.

Re: Scrum is fragile, not Agile

#177

Post by taeric »

Reading the comments on this post are truly sad. The amount of "me too" juxtaposed with "actually, this isn't a true scotsman" are truly mind boggling.

I wish there was a prescriptive way to successfully make and deliver software. I have seen very little evidence that there is.

Re: Scrum is fragile, not Agile

#178

Post by LaGrange »

tootie wrote: post #132
wpietri wrote: post #12

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…

> 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.

Even if so, that would be in itself a failure of Scrum. A process that works only sporadically and only with exceptionally well organised groups ain't really all that much.

> It requires a high degree of trust to say "we'll pay you $XM in exchange for X sprints of whatever we prioritize with no fixed end state" but that's what you need to be agile.

...no? It requires a well-defined end-state, and that includes not defining the irrelevant. It's not really "give me $XM and we'll deliver anything from accounting software to a really nice puppet."

Re: Scrum is fragile, not Agile

#179

Post by swinglock »

xyzzy_plugh wrote: post #170
mixmastamyk wrote: post #105

Earlier quoted context omitted.

> "How could it possibly take that long? How do you not know how long it will take?" Well, if they really said that, you can just dismiss the comment as incompetent. A witty retort may be in order if a non-technical manager is in earshot, e.g.: "How long would it take for you to earn a green belt in karate?" "Hmm, what does a green belt entail?" "Exactly, you don't even know what you don't know, yet."

They did, and I replied "We don't know because we've never done this before, and we can only compare to the most similar work we've done, and any existing data." Before I could say more, they I interrupted: "You have to know, it's your job, or you don't know what your doing," or something along those lines. It was the most heated I've felt. I know what I'd reply with today, but I was younger and more naive then.

What would you reply today?

Re: Scrum is fragile, not Agile

#180

Post by iqihs »

anon1m0us wrote: post #14
clumsysmurf wrote: post #3

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…

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.…

This pretty much sums up my experience with Software Dev at one of the Big 4.
Post reply on HN