I find Scrum stand up meetings humiliating

[VectraMan]

To come back to the article that criticies Agile.

The key principle of Agile:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

The emphasis on early delivery puts pressure on developers to "deliver early". Hence things get chucked out that are full of bugs.

You highlighted the wrong word. I'm the first to be cynical about these things, but the bit that always seemed absolutely right to me was the idea of maintaining a near releasable quality code base all the time, which means fixing the bugs before you add new stuff. Developers have always been under pressure to deliver early, and it's that that tends to mean bug lists being ignored "until we have more time", which of course you never do.

Where it falls down in reality is that marketing people always want to do a big product launch with a long list of features, and saying that you've got something without many features but is reliable doesn't wash. You wouldn't buy a car that turned left really well and really reliably, but couldn't turn right yet because that feature hadn't been developed.

[oscarose]

For years, I've found myself a bit grumpy at stand up times. It pains me to give an update and I now know why. It's because I find them degrading. They're never about 'geeing' the team up for the day and moving blockers etc. They're basically status meetings. I hate standing there, proving what I've done, watched by team leads, managers and BAs. They make me feel small and back in school.

Does anyone else hate this pointless concept?

Agreed. I think some companies may claim to be 'agile' but don't understand basic scrum principles.

[oliverson]

I've been working on SCRUM / agile projects since about 2008 and from an optimistic start it's ground me down to the point where I really wish for a waterfall approach again. In fact in those 7 years I landed a 6 month contract out of London at a place I had been before. When I arrived the manager gave me a spec. Almost bullet proof it was. It was so refreshing to have something to work from and it was delivered more or less on time.

Contrast this with a well known investment bank client where the dev team had to sit down and come up with a plan for the next 6 sprints. I kid you not!

[BlasterBates]

I've been working on SCRUM / agile projects since about 2008 and from an optimistic start it's ground me down to the point where I really wish for a waterfall approach again. In fact in those 7 years I landed a 6 month contract out of London at a place I had been before. When I arrived the manager gave me a spec. Almost bullet proof it was. It was so refreshing to have something to work from and it was delivered more or less on time.

Contrast this with a well known investment bank client where the dev team had to sit down and come up with a plan for the next 6 sprints. I kid you not!

I empathise with this.

I worked in a bank where the analyst wrote a spec and the analyst who wrote the requirements then tested it. Working there was very easy, implement what they tell you make a few changes during testing and out the door it goes.

I now work on an Agile project, the product manager writes a vacuuous three line story that has to be done in the next sprint and some clueless testers have to ask me how it works, lots of misunderstandings due to many informal discussions where requirements that were discussed in the previous meeting get contradicted in the next meeting while discussing other requirements, I usually find it takes about 18 discussions to pin them down sufficiently to deliver something that is 80% of what they need .....the system is full of bugs and too many people working in parallel in a "detached way".

I was just thinking on the same lines.

[rocktronAMP]

This is not Agile even with a small "a". It is read like regular daily meeting with someone with authority to hand over tasks to developers. This sounds like ant-Agile and project meeting about tasks and planning. This is not SCRUM at all.

Totally and utterly pointless. Been in a room with 30 team members before some offshore - took over an hour.

Nobody is really interested in what anybody else is doing, they just want to get their piece out of the way and then get on with it.

Yet another pointless methodology, supposedly agile but now an industry. We've been LEANED everybody!

Sadly, you have not worked with business yet that gets even iterations, stand ups, retrospective, sprint planning right even for SCRUM. There is a several clients that I have worked that just take elements of Agile and then rubber stamp it as "We do Agile. Yay!" I have seen may be two businesses that work effectively. One business knew they had an issue with a big team and immediately split the team into two business functions for their daily stand ups. The result was two daily stand up teams and shorter meetings. The loss was the regular communication between the teams.

I am not SCRUM master (who are they in 2015) but an experienced developer. I sounds like your project is driven by a clueless Project Manager. Unfortunately for you, as a temporary consultant, you are just going to have to suck it up and ensure that you build relationships with the other members of your team that are also struggling with work. That is true, if you intend to fulfil the terms of your contract.

All the best

[oliverson]

Sadly, you have not worked with business yet that gets even iterations, stand ups, retrospective, sprint planning right even for SCRUM.

Not sure how you draw that conclusion. I've only mentioned the extremely bad examples.

Some are better than others but fundamentally I believe SCRUM is flawed. Actually I'd refine that by saying I fundamentally believe that Waterfall is better.

[SpontaneousOrder]

They are trying to do agile at my current contract.

But they have 1 stand up meeting for the whole dev team (10 people) who are all working on different things.

It goes fast enough, but it is pretty much a waste of time for many of us, as we are about a ton of stuff we are not working on.

Context - "It surrounds us and penetrates us. It binds the galaxy together".

People seem to think that a daily scrum/standup will do something magic to make things better - rather than understanding it's primary purpose is to maintain context throughout the project & across the team.

If you share no context then a standup is pretty pointless. I know that pain.

[SpontaneousOrder]

Agreed. I think some companies may claim to be 'agile' but don't understand basic scrum principles.

Just like clientCo claim to do CI because they have a jenkins build, yet only integrate feature branches just before quarterly release

[BlasterBates]

Just like clientCo claim to do CI because they have a jenkins build, yet only integrate feature branches just before quarterly release

This is the conventional way of doing things, after everything has been very carefully tested, and QA gives clearance. The system then runs through a regression test and the odd fix added before it gets the green light.

In Agile all sorts of half baked buggy functions are being continuously merged, so you have no idea what works and what doesn't and you go through cherry picking to get rid of the non-cleared stuff and have to deal with all the bug tickets of the buggy stuff that gets rolled out.

[SpontaneousOrder]

This is the conventional way of doing things, after everything has been very carefully tested, and QA gives clearance. The system then runs through a regression test and the odd fix added before it gets the green light.

In Agile all sorts of half baked buggy functions are being continuously merged, so you have no idea what works and what doesn't and you go through cherry picking to get rid of the non-cleared stuff and have to deal with all the bug tickets of the buggy stuff that gets rolled out.

The point of CI, though, is that every single commit to mainline is *theoretically* production-worthy. That is to say, that it doesn't have to be turned on in production - but everything is production quality. That means ALOT of automated regression testing.

The difference between CI and CD is that CD means that it has been proven to be of releasable quality (turned on or not) on a production-like environment (i.e. you press a button and it gets deployed - no expectations of days of monitoring required before it's deemed a success).


Just because people do CI wrong, doesn't mean that CI is a bad idea. The whole point is that it is supposed to reduce bugs because more frequent integrations/deliveries/releases means smaller changes = less risk & easier fixes.

More releases = less risk. More integrations = less risk.

many of the big boys in this area (spotify, easy, flickr, netflix, etc) deploy to live several dozen times per day!


You can choose between mean time between failure, or time to to restore service.