Anyone else have to spend hours reviewing "pull requests"?

[TwoWolves]

For all the talk hardly anywhere does agile correctly, mostly because management think it's a route to hot-house coding and unrealistic deadlines.

I was getting PR notifications all night as today is end-of-sprint and nobody on the team could meet the timescales demanded by product. It's like this every sprint and senior devs are burned-out as they code to the slave drum.

[suityou01]

Thanks DP

This thread has cheered me right up. My work has rolled out JIRA and announced we are now agile.

My main problem these days is that experience tells me fairly accurately what comes next, and usually these car crashes happen in slow motion while I just try and stay sane.

Effectively now the development role has become commoditised to the extent that your daily grind is just taking the next JIRA ticket to work on. You don't even need to turn on your brain.

What has happened is that the developers are now completely isolated from the business, the business write user stories which get pumped into JIRA and off we go. Then we get into UAT and the defects read like user stories. It's utter madness and a trap I have seen businesses fall into easily.

IT development has always been seen as an overhead, and the solution is always "agile". Businesses love things that seem like less work. Wow I just rattle off a quick user story and hey presto I get my change? Seems like a good deal huh? Until UAT of course.

So you get agile requirements, waterfall testing cycles with "mini sprints" and "uat tweaks" and then go live with something that has changed wildly during the testing cycles and is almost impossible to stabilise and you're then into "hotfix" territory. Week before last we had a release, the following week we had a midweek hotfix and and end of week hotfix to the hotfix. But this all happens below the waterline and the extra effort this causes the developers goes unseen and we have to play catchup with the sprints we should have been working on while doing the multiple hotfixes.

[NigelJK]

I'm sure 'show and tell' is something the snowflakes understand, and it's central to Agile promotion.

BTW TFS is now my goto tool. It's all there if you want it, including the awful GIT, it's open source etc etc. It's also a doddle to move your greenfield dev Agile project to KanBan when you want to manage it properly. No need to mix 'n' match as it also handles CI/CD from with VS if you wish. On-Line TFS is also great for distributed teams.

[suityou01]

I had a brief spell managing the team for the first 6 months of this year after the previous PM got promoted. I was adamant that if I took on the role and did a good job then the job should be mine, and I didn't want to spend 6 months working my butt off only for some johnny come lately to join and inherit all my good work.

In those six months I managed to get things relatively stable. There were daily standups, playback sessions, formal UAT, lessons learned et al.

After 6 months I was told thanks very much for all your work, here's the new PM to take over now. I was fuming. Apparently company policy is such that until 2 years service I was not eligible for a promotion, and my boss was just a rookie that should not have made these promises.

So we had regular playbacks, and now we don't.

[OwlHoot]

I’m working with an agile team that don’t believe in a test system. You push your code and hey presto it’s on production.

The idea is that if there is a bug it’s self evident and you can fix it straight away. ...

That's madness - The bug may be quickly fixable, but what about its consequences, in corrupt or even lost data, and company reputation (if the software is customer facing)?

Maybe permanent data isn't always an important consideration in certain apps, such as online games. But it sounds like your agile team will come a big cropper before long

[suityou01]

That's madness - The bug may be quickly fixable, but what about its consequences, in corrupt or even lost data, and company reputation (if the software is customer facing)?

Maybe permanent data isn't always an important consideration in certain apps, such as online games. But it sounds like your agile team will come a big cropper before long

You are a dinosaur Owlie, this is a new fad called "Devoops".

[d000hg]

DVCS is nothing to do with Agile, it's just far better.

What is your preference, just people randomly committing un-tested code to the master branch? Pretty sure the big boys have been using the equivalent of pull-requests for decades, long before Git. I remember reading an article on MS' custom version of Perforce for Windows builds.

[TheCyclingProgrammer]

What has happened is that the developers are now completely isolated from the business, the business write user stories which get pumped into JIRA and off we go.

If this is happening then the business has no clue about how to implement agile development properly or what user stories are supposed to be.

User stories are not supposed to be fully formed use cases with an exhaustive list of implementation detail and acceptance criteria. Certainly not at the initial planning stage.

A user story should be a fairly high level overview of a feature - the best way I've heard it described is a "promise of a conversation". User stories should be groomed and discussed between the business and developers during release and sprint planning. The first thing a developer should be doing when they pick up a new user story - unless its really straightforward - is talking to the business owner of that story directly. The owner may be a BA/customer proxy, it may be an actual end user, but the important thing is to have the conversation. The customer can help clear up any misunderstandings a developer might have. Sometimes a developer may have better suggestions for how something should be implemented than the customer. The end result of the conversation should be an agreed approach and acceptance criteria.

[TheCyclingProgrammer]

DVCS is nothing to do with Agile, it's just far better.

What is your preference, just people randomly committing un-tested code to the master branch? Pretty sure the big boys have been using the equivalent of pull-requests for decades, long before Git. I remember reading an article on MS' custom version of Perforce for Windows builds.

There's a school of thought that pull requests and indeed branching, are anti-patterns. One of the core practices of continuous development is "trunk based development". In order for this to work it requires a lot of discipline, real-time code review (including pairing), a strong test suite (from unit tests right up to automated acceptance tests).

I think its an interesting idea, I agree with a lot of the principles - , but also think it would be hard to implement in a lot of teams:
Trunk Based Development

The compromise version of TBD is to only have very short-lived branches (less than a day) and use the Github pull request model for code reviews before merging.

[NigelJK]

Always preferred a gated check in and preferably configurable once you have confidence in the coder(s).