[keyraycheck]

+1

I went all the way from Agile maximalist to common sense-ist.

For me agile these days is simply:

- talk to your team to sync often but short

- seek feedback (from stakeholders, ideally users)

- allocate time to work on your backlog so it nice and tidy

and technical stuff:

- release early, release often (i.e. CI/CD/devops stuff)

- automated testing, regular code reviews

- refactoring, working with small commits/PRs

More a common sense, than a "process" or "ideology".

[happymellon]

I would add, if something doesn't work then change it.

This is the one thing that "failed agile" hits against. Large organisations want everyone to use their same crappy Jenkins pipeline. Which means when it keeps breaking then no one can do any work. No one can fix it, and no one is allowed to switch it for a service that isn't down for half a day most days. That isn't "agile".

It derails everything else in the process, what's the point of a retrospective if the most painful parts was because someone has decided outside of the team that you have to use OpenShift for your Kubernetes, but then hires folks who don't know what they are doing and you can't just shift to a managed service until they sort their shit out?

What's the point of standups to get updates if most days people are still stuck on their ticket because the mandated CI pipeline is stuck due to a lack of workers?

I see it in all these complaints about agile, that they don't grasp that they were never given autonomy in the first place. It was always only lip service.

[troupe]

> if something doesn't work then change it.

And especially if you change something, make sure you have someway to know if you made it worse and need to go back to what you had before.

[jollofricepeas]

Agreed.

Note that ALL of these can be summed up in one phrase that I tell my teams often…

TIGHTEN

YOUR

FEEDBACK

LOOP

This is literally the key to life (besides 42) and everything. Want a better relationship with your partner, pet, friends, boss, code, family then tighten the loop.

[dgb23]

That’s very good advice for day to day tactical approach:

- small changes, fixes, additions

- tests, optimizations, refactoring

It’s what you do to move forward iteratively with approaching deadlines.

But to not get stuck in local maxima you need some time off from feedback loops and tactics. You need time to think, design, experiment, sleep. You need time for creative, strategic thinking. Processes, rules, feedback loops, deliverables etc. are all a hindrance to that.

[mike_d]

That is exactly the failure of all the various management methodologies - they are built on the false assumption that all feedback is valuable and if something isn't going right you must not be getting enough feedback. What is the value in getting bad data faster? Can we not trust a developer to build something without deferring on every decision?

We need to get back to engineering as an art form, not factory work.

[sveme]

That needs to be balanced as well, same as all things. A retro every two weeks is a lot and brings too much overhead into the process. Same with the constant refinements and groomings and plannings and whatever. A team or a subteam needs to have uninterrupted autonomous time to dive deep and get things done. That's fulfilling work, from my perspective. Rhythmitize work into periods of quiet, focused implementation work and team work where people investigate, research and plan new features and refactorings.

[jollofricepeas]

Here’s what we do:

- Kanban (no sprints)

- (45 min) Weekly grooming session

- Thrice weekly stand ups (async)

- (1 hour) Retro every two weeks (sometimes we skip it or it becomes a show-n-tell)

- (30 minute) 1:1’s monthly for seniors, every other week for juniors unless requested more frequently

- Optional (1 hr) themed mob sessions / office hours throughout the week. You bring a problem and the group that shows up will work on it with you. Seniors/IC’s are required to hold office hours at least once a week.

- NO OTHER MEETINGS; engineers are asked to block out their lunch/personal time and refuse any non-essential meetings. They have the right to request meetings be rescheduled to appropriate times or moved async.

- NO MEETINGS OF ANY KIND ON FRIDAYS

[exitb]

Doesn’t it become something akin to micromanagement, when tight enough?

[qikInNdOutReply]

Its also a good way, to destroy programers productivity. Put them into large offices, interview them on the project status every hour on the hour.

[laserlight]

Be careful, because tighter feedback loops might result in a lower signal to noise ratio. When noise is reacted as signal, things might become worse. To be clear, I'm not arguing against tight feedback loops. Our current feedback frequency might be looser than the optimal, after all. We need to be more cautious with what we are doing, though.

[irfn]

and dont forget that feedback means measuring data accurately without biases.

[Lio]

I’d add one thing to that list:

Control the amount of Work In Progress by the team.

I’m not sure if that counts as common sense or not but I see it as vitally important.

[hurril]

Common sense is a dumb term because it tends to mean whatever the person invoking it considers good.

Having worked as a programmer since 1999, I can say that these things were not part of the processes and ideas when I started, at the places I worked. Interpret that any way you want.

I like agile/ scrum/ whatever and what I mean when I invoke those terms, is the list enumerated above.

I dislike the bullshit derivative terms, however. The burn-down charts, estimation poker, story points and all that. (Sure - the poker might trigger a thorough discussion about controversial estimations, so I guess I'll allow it.)

I also really dislike the concept of the daily standup for non-juniors.

[ac50hz]

+10

That’s common sense, otherwise we’re just not taking real-world problems into consideration.

[ac50hz]

+10

I like this focused list. I’m always in favour of understanding the need for methodologies yet at times too many people use a methodology name as an excuse and alternative to saying “I want it now, I don’t care how, and I’m not interested in excuses nor if there are problems. But make sure there are no problems.”

Common sense, teamwork and cooperation can help us embrace the salient features of different methodologies without the barriers and no-entry poses sometimes presented by leaders or masters in the name of leading-edge box-ticking, often forgetting that we’re working with people. I’ve not seen many unhappy yet productive, professional and inclusive workers, in any field. Explanations, regular feedback and carrying a team with you can help to reduce stress of everyone in the team.

Processes are key to this, irrespective of the ideology.

[flir]

In theory you can go even smaller: a way of measuring output, and a regular retrospective to improve the process. In other words, a feedback loop that improves your process over time.

Of course it would be dumb not to include all the stuff you mentioned at the start, because we've learned from previous projects that it works. Might as well stand on the shoulders of giants. But it's not the absolute, minimal core.

Personally I'm not convinced that "tighten your feedback loop" is good advice, because I interpret it as "shorter measurement intervals", and the shorter they are the more noise there is in the measurement. But the beauty of iterating the process is that we can try it and see if it works.

[jshen]

I agree with this, but it misses the thing many teams need and that is a process to reliably hit dates they commit to.

[lmm]

95% of the time the reason teams "need" that is bullshit internal politics and everyone is better off if you can structure the organisation to not do that.

[therealdrag0]

Why is that?

My current team only estimates projects not tickets and does not do scrum, and I don’t notice a difference in performance from scrum teams I’ve been on.

Furthermore, I worked on a 18 month project that was estimated by someone who was not on the team that implemented it and it was implemented on time without overtime, and without any special process. Maybe that was unicorn, but it happens.

I think just having a manager/tech lead that cares and maintains priorities is all it takes to stay on track.

[Mtinie]

To reliably hit dates, scope of effort must be well understood and it cannot change once a commitment is given.

The former is (generally) within the control of the team who is responsible for hitting the date. The latter, (generally) is not.

The process is less important than the people.

[jacquesm]

> but it misses the thing many teams need and that is a process to reliably hit dates they commit to

40 years of IT experience lead me to believe that this is only possible for the most trivial of projects with nailed down specifications and where the party building it has relevant domain knowledge. In practice such projects don't really exist. Trivial IT projects are rare, specs change, scope creep is a thing and domain knowledge is built up slowly over time.

What is necessary is that the work does not occupy more time and effort than it strictly requires. That is still a hard problem, but much less hard than to find a way to hit dates that you commit to, unless you give yourself ample room to deal with the realities of complex IT development work.

[pif]

The most usual situation, in my experience, is that a team is required to hit a date that someone else committed to.