I work in software development and I hate the "Sprint Model"

[bUU]

Originally Posted by WRM20

Until a user tries something, and creates an edge case that was never considered, either by the business requirements or the development team. Every application that is even slightly complex will have bugs occur.

Precisely. It is terribly naive - and corrosively dangerous to the effectiveness of the organization - to categorically ascribe defects to improper development and testing rather than inadequate resourcing, consumers changing their minds (or having different minds) about what they want*, and/or the innate complexity of the work.


_____
* The reality is so far from what the previous poster described that we no longer bother trying to classify reported problems as software defects versus regressions, since the majority of such reports are simply design change requests in disguise.

[charlygal]

Originally Posted by bUU

Precisely. It is terribly naive - and corrosively dangerous to the effectiveness of the organization - to categorically ascribe defects to improper development and testing rather than inadequate resourcing, consumers changing their minds (or having different minds) about what they want*, and/or the innate complexity of the work.


_____
* The reality is so far from what the previous poster described that we no longer bother trying to classify reported problems as software defects versus regressions, since the majority of such reports are simply design change requests in disguise.

While defects will always occur, what about proper story grooming? Consumers changing their minds is not a defect. It's a change. By complexity of the work, are you saying the task was too difficult to have been developed properly? Could that story have been broken down to multiple smaller stories to alleviate some of the complexity?

I'm not sure what you mean by inadequate resourcing? Not enough developers? A skills or training issue? Has anyone raised their hands and made management aware of the resources issue?

[BigDGeek]

Originally Posted by branh0913

Retrospectives are not about throwing people under the bus. First no managers should be present unless invited by the team anyway. But if a retro turns into a finger point session or CYA fest then you're missing the whole point.

I know what a retro is for; unfortunately most of my teammates don't seem to get it. We have only two people in my group (myself included) with Agile experience at any company but this one and we're often meeting each others' gazes and almost imperceptibly shaking our heads during sprint ceremonies because it's so ridiculous.


Our manager doesn't attend retros (or any other sprint ceremonies), but our scrum master also rarely creates action items after retros and if he does, he never follows up on them. The format for retro is different every time but the "lessons learned" are always the same. Since any changes I suggest don't involve a way to immediately make burndowns look awesome, I'm ignored. Since we rarely have green sprints, there's a lot of covering of asses going on. I don't have to try to cover my ass; all my tasks are done, my hours are burned down, and there's a paper trail a mile long of me picking up work for other people. I'm good to go.


Yet still...when our BA doesn't do his job right and QA doesn't know enough about the applications to do theirs (and they're taking their cues from the BA anyway), stuff goes out to prod sometimes configured incorrectly. That happens to all of us, and we hear the same excuses from both of them every time. At least the devs are trying to fill the gap but when the BA never learns from his mistakes and QA refuses to leave their desks to talk to the business users and just test the acceptance criteria in user stories, it falls to us to do their jobs too.


Our scrum master calls this "collaboration." I call it "functional incompetence."

[dspguy]

Originally Posted by branh0913

Once again this is the most common complaint. This is NOT, I repeat NOT a failure of Agile. It's a failure of sprint planning and grooming. If people aren't given Spikes or research stories, then they can't properly estimate the level of effort needed for a task. Also, many teams have moved away from estimates and have gone with story points. Which I think works better than estimates. Also I feel when a task becomes too monlithic and time consuming, it's a failure of the scrum master to further decompose task. These things should be brought up in retrospective WITHOUT the presence of the manager.

My team just had agile training once again. Many were new to it but there were some "veterans" there. The instructor said something that has been true for the last 8 years I've been doing this... that the Product Owner is nearly always improperly assigned. It isn't the customer. It is a proxy to the customer that understands the customer's needs and can relate it to the team and guide the next sprint iteration. And it is a full time job. The backlog isn't something that is filled out 10 minutes before the next spring planning meeting. And it generally should NOT be a manager.

Yet, even after this training... who is the PO? The program manager. I feel like they don't want to give up that position since it would box them out.

I like many aspects of Scaled Agile Framework (I think that's what it is called now). However, there is still too much archaic thinking that prevents it from working properly.

[djikstra]

Originally Posted by pappjohn

Management loves agile sprints because it
shows artificial progress. They can claim their team accomplished such and such in a few weeks, but in reality it was insignificant such and such. The management above are non technical and don't know the difference.

It usually creates chaos and inneficiently when everyone is trying to show progress on a day-to-day or week-to-week basis. From a developer standpoint, I see developers who create pull requests for code they haven't tested, because they want to move the task from "In Development" to "Code Review" so they can say at standup "Yesterday I got this into code review" to make their manager happy. Then they have to go through 5 code review iterations whereas if they took more time to develop and test locally they would've only had 1 iteration and fewer total engineering hours spent across the team.

The show Silicon Valley has a funny scene where the manager Jared of their startup introduces work tracking and the developers start competing against each other and becoming obsessed with moving their post-it notes across the wall. One of the developers calls it "MBA Psych 101 bull****" or something like that.

[djikstra]

https://m.youtube.com/watch?v=oyVksFviJVE

[bUU]

Originally Posted by charlygal

While defects will always occur, what about proper story grooming?

Ice cream has no bones.

Originally Posted by charlygal

Consumers changing their minds is not a defect. It's a change.

True, yet I don't believe that you've carefully enough assessed the reality to know the difference in the context of your earlier, preposterous statement in Post #112, which is what this whole tangent has been about.

Originally Posted by charlygal

By complexity of the work, are you saying the task was too difficult to have been developed properly?

Many things that we want as consumers of software are naturally complicated. We are aiming to reduce the complexity in our own lives by having software obscure the complexities. The problem is that the complexities are often intractable. To help you understand, I'll provide a lay-person example: Consider weather prediction. How can, after so long, they still get it wrong sometimes? Though it might be difficult for a lay-person to appreciate, some of the critical aspects of complex systems are as unpredictable as the weather, and therefore the software is going to have defects despite doing everything right. For software like that, it is a never-ending cycle of refinement, recalibration, and improvement - not the kind of defect-free reality that your poorly-chosen words imply.

Another aspect of complexity is that of the complexity involved in eliminating certain defects, especially defects which have a low incidence, and are such that their impact can be remedied much more efficiently than prevented. While unlike the weather prediction example, above, these certain defects could be eliminated, it is possible for the remediation to be deemed not worthwhile, given the cost of implementing and/or maintaining the solution. The best business decision, more often than many consumers and prima donna software developers are willing to admit, is to leave the matter for remediation on a case by case basis when the defect presents. The goal of zero defects in all cases has been thoroughly discredited from an economic standpoint.

Originally Posted by charlygal

I'm not sure what you mean by inadequate resourcing?

Or are you just looking for a way to distract attention away from what you wrote? I'm not sure. My point was clear enough from what I wrote, so your asking the question makes no sense, even if asked by a lay-person.