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

[happymellon]

This is true, measurement is important and if it is worse can you tell if the original bad part improved and look at a hybrid of actions, however the ability to change in the first place is always lacking with people who say that Agile doesn't work.

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

[afro88]

Also, getting an app up and running. Often times it's better to hack away at a (truly minimum) mvp and then iterate on that. Than try and iterate your way to an mvp.

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

[andrei_says_]

But isn’t it the managers’ implicit goal to make it as predictable, modularized / interchangeable as factory work and workers.

the Agile Industrial Complex realized they can sell that vision to managers, despite it being unachievable.

That promise is so alluring, it’s blinding.

[mathw]

My company have mandated that my team use sprints, despite us having previously proved that sprints are a bad way to handle our workload (we used a kanban-like system for a glorious year or so and we were actually way more productive in a measurable manner, and also a lot less annoyed). The reason? Predictability.

Except you can also measure that we're not hitting any predicted goal times, ever, because our sprint system is incompatible with the nature of our work supporting live systems and simultaneously developing new features. We're regularly taking on work from outside the sprint half an hour after sprint planning, because something exploded and we're the ones who have to fix it.

It's completely impossible, but the vision of predictability has blinded management.

The number of times there's a card on the retro board under "Stop doing" that just says "sprints" on it...

[andrei_says_]

I believe this has to do with managers being required to constantly estimate cost, time, and ROI with precision, minimizing risk.

I like Basecamp’s shape up methodology: make bets of efforts that are worth 6 weeks of the team’s time, commit to the best one, timebox it. If it takes longer than 6 weeks, throw it away. This way the risk is limited to six weeks.

Few managers would be willing to stake 6 weeks of a team’s time though.

[webmaven]

> I believe this has to do with managers being required to constantly estimate cost, time, and ROI with precision, minimizing risk.

Well, they think they're minimizing risk, but at best they're just minimizing uncertainty, and the result is predictably low productivity.

[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?

[meheleventyone]

If all you concentrate on is short term improvements then... sort of?

Making iteration faster let’s you see the results of changes you make faster, that’s the benefit. If you’re iterating faster than you can make meaningful changes then you won’t see any change by definition.

Iteration length is also context dependent. For a multiplayer game I really like being able to see my changes immediately when working on it, I love being able to iterate with other devs on some idea where each iteration is in minutes and we’re chatting about it together but we only test the game itself “as it’s meant to be played” with anyone outside the team once a week. That’s part logistical and partly anything shorter than a week doesn’t usually show enough progress. If there’s some bigger change we’ll also keep our work iterations but pause the larger play tests until it is done.

Short as possible is good advice but you’ve got to look at your own context and make sensible decisions. You can also look at it like following a gradient, if you’re unable to make bigger changes then you’ll just be optimising towards some local maximum.

Micromanagement itself is more about the amount of agency to decide what to do at each iteration.

[r_hoods_ghost]

Even worse it means you are always reacting to the latest or "loudest" issue (like the CEO wanting a feature implemented that no one will use but will impose a maintenance burden) and never standing back to evaluate what is valuable for the majority of customers or product.

[snovv_crash]

It doesn't necessarily mean that management is giving the feedback.

It could be coming from tests, from CI, from the QA team, from customers, from other engineers in your team, or, failing all that, then yes from management.

But if management is giving feedback that is hard to reconcile with everything else, at this point you can point to CI, the previous tests that were added based on other requirements, feedback you got from customers etc. as justification for your existing actions. It means you're operating with a lot less assumptions because you get data validating what you're doing (and where you should fix things) every step of the way.

[exitb]

If I had a perfect understanding of both technology and the problem domain, I wouldn't need feedback. Yet, usually we find ourselves in a different situation of less than perfect understanding of both, so we seek feedback to avoid going in a wrong direction. The less understanding, the more of it we seek. But there has to be a logical limit to that, otherwise we could come to a conclusion that things could be accomplished by someone with nearly no expertise, given enough feedback.

The secret lies in the fact that neither giving, nor receiving feedback is free.

[laserlight]

I would like to interpret “feedback” in the parent comment as communication. And I think we should distinguish between frequent communication and micromanagement. One may report to their manager frequently. Doing so has the benefit of letting manager communicate back any context they might have regarding the current status. Perhaps, that problem has already been solved in some other situation. Or, the manager has experience in a similar domain and can give direction. Unless the manager dictates a direction, doesn't leave enough room for decision autonomy, or begins working on a solution rather than leaving it to the engineer, I wouldn't call it micromanagement.

[ac50hz]

In my experience, if the management, processes and teams aren’t trusted then it can turn into unwelcome micromanagement.

Engaging with people, who have different motivations and reasons for being in a job, and stripping away often unhelpful implied titles of rockstar programmer to QA robot, can help everyone to see the big picture and in turn to see how their contributions, their cogs, fit into that picture.

Production-line programming can be left to new automated systems, whilst we can embrace and capitalize on people exercising their intellect for productive, feedback-oriented work.

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

[laserlight]

> Sure - the poker might trigger a thorough discussion about controversial estimations, so I guess I'll allow it.

I believe all these tools have their place. But they are more frequently used by management to exert power over engineers. “What a dumb take. That feature obviously will not take that long. You are over-cautious as always.” “We had decided that this feature was 2 story points. Why did it take that long?” No, dumb fuck. It was your decision, not mine. I had argued against it, but you didn't listen.

[flir]

That's not my experience. But if it does happen, does it matter? All that happens is that less work goes into the next sprint, right?

(I'm suggesting that the problem in your process might lie elsewhere - with mapping points to time, maybe, because the points system should be self-correcting to that kind of gaming).

[laserlight]

Totally agreed. But such understanding is not the approach of power-game players in the first place. For such people, agile is a tool of oppression.

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

[yashap]

Depends on the company.

When I worked for a larger company with a pretty mature product, this was true - deadlines were internal and arbitrary. It also helped that the product was more of a “nice to have” for our customers than “absolutely crucial” - they didn’t truly NEED anything it did (it was software to make social media marketing more efficient).

But I’m now at a smaller Enterprise SaaS startup, where the product is absolutely crucial to the customer’s work (core operational software for public transportation agencies). The reality is that the product isn’t yet mature enough to close big sales without making sales commits. I dislike sales commits, but we’d legitimately lose every big RFP unless we commit to adding the ~2-5 features they really, truly need that we don’t yet have. And sales commits come with real, external due dates, that you need to be able to meet if you don’t want to piss off your customers. You need to be able to say “yeah, we can build X by date Y”, and then actually deliver on that.

[irrational]

This is one of the reasons I’ve stayed where I am for so long. I get paid a nice six figure income to work on a training platform that is useful, but not critical. It is a low stress job with little to no critical dates.

[lmm]

> The reality is that the product isn’t yet mature enough to close big sales without making sales commits. I dislike sales commits, but we’d legitimately lose every big RFP unless we commit to adding the ~2-5 features they really, truly need that we don’t yet have. And sales commits come with real, external due dates, that you need to be able to meet if you don’t want to piss off your customers.

That's just pushing the issue one level higher. Most likely both the customer and you would be happier if you were able to iterate with them rather than building the thing they thought they would want however many months back. (And while it may be harder to set up that kind of contract, it's absolutely possible)

[lelanthran]

> Most likely both the customer and you would be happier if you were able to iterate with them rather than building the thing they thought they would want however many months back. (And while it may be harder to set up that kind of contract, it's absolutely possible)

Possible? Sure. Just like it's possible that I could win the national lottery.

In practice, multiple companies bid for contracts, and all of the bids have to be of the form "Deliver $X in $Y months for $Z dollars".

No company is going to accept "Choose us, and we'll work until you're happy with the product or you run out of money, whichever comes first".

Agile doesn't work where there's competition for the project. It can't, because the buyer of that project cannot evaluate "we'll work until your money runs out" against the other bids that state "$X in $Y months for $Z dollars".

Agile works well for internal teams that are sheltered from having to provide competitive bids.

[webmaven]

One approach is value-based contracts: "we'll work with you and charge X% of the value we deliver."

[yashap]

The problem is winning the RFPs. There are some core features and integrations that they really, really want. If we don’t have them, and won’t give a firm commitment to building them, we lose the RFP.

“We’ll work collaboratively and evolve the product over time in yet-to-be-determined ways” can work when you have an established relationship and 2-way trust, but there’s not much of that during an RFP. If a competitor commits to their biggest asks, and we don’t, we lose the RFP.

[holoduke]

Its an example of bad leadership. You see it often. Higher management thinks product x can be ready in a y period. Reality is much different. One of the key reasons why companies and products fail.

[jshen]

This is not true for most. Imagine going to a contractor to get a house built and they tell you that they can’t tell you what it will cost or when it will be done.

[cubano]

You have obviously never built a house in the U.S., otherwise you would never make such a statement.

As almost everyone knows, construction delays and cost overruns are the norm, not the outlyer. Construction projects here very often suffer dearly from the "2 more weeks and/or a couple more thousand dollars" overrun issues.

In fact, I'm sure at least several people who have been trapped in a home renovation nightmare LOLed deeply after reading your post.

[midoridensha]

>In fact, I'm sure at least several people who have been trapped in a home renovation nightmare LOLed deeply after reading your post.

These stories are SO common (and I've seen it in my own family too) that I truly question the sanity of anyone who takes on a home renovation project.

[jshen]

I’ve worked on the building of major resorts that many people in this thread have probably been to. I’ve seen this done well before, and I’m happy to compare credentials if that’s the route you want to go. Then we can see who LOLs.

[jacquesm]

A major resort is a project that has very large contractors involved and where a part of the upside for the contractor is how well they can manage the buffer they built into the quote for the project. The smaller that buffer the bigger the chance they will win the bid but also the bigger the chance that they will end up losing money on the deal.

Houses (not housing tracts) tend to be built by much smaller contractors who are in absolutely no position to absorb any setback without going bankrupt, you can't apply the rules for 'big business' to small time operators and expect the exact same outcome.

Constructing resorts also has all kinds of economies of scale that building individual houses does not.

[foepys]

I don't know about the US but in Germany this is already the case. You get a rough estimate but nothing is set in stone.

Overshooting deadlines and increasing costs due to materials not being available or them suddenly costing twice as much is normal.

Also coordination between all the various contractors is always getting messed up because the person putting up the scaffolding didn't show up, so the plumber cannot work and cannot come back for 3 weeks, which messes up the plan for the drywall, which gets pushed back, and so on.

[jshen]

But they give you an estimate for cost and time, and are reasonably close to it. I.e. it doesn’t cost 3x the estimate!

They could probably do it more accurately but it would lose them bids, so they knowingly low-ball it. You shouldn’t have that problem inside a company doing software.

[Lio]

Of course you have that problem inside s company building software.

Engineers low ball partly because they don’t know what’s involved in a new piece of work. Like walking between two points on a map; they don’t know what they’ll run into on the ground.

Managers and stake holders then bully the engineers into lowering the estimates because even that’s not quick enough. Worse, they scale the team without discussion without realising that will make the project harder to deliver.

[jacquesm]

That's pretty much every contractor that I've ever worked with. It's all based on estimates with set minimums, buffers in time and money to deal with the weather and other outside influences and even provisions to deal with the changes in price for raw materials.

The only way you are going to get a hard quote is if you buy a prefab or a house that the contractor has already put up multiple times (and even then there will be some room for adjustment). Oh, and foundations are a completely different story.

[jshen]

Yes, I think we are saying the same thing. You use buffers and other means of flexibility to hit a target launch, and it works most of the time but not all the time.

[tmlb]

Makes sense only if you assume building software is like building a house. Imagine getting an author to tell you when the novel they are writing will be finished?

Or this: imagine seeking an estimate on when a house will be built, trimmed, painted, furnished, decorated, and filled with every item needed practically and for comfort by the homeowner.

It’s a living process that requires continuous reassessment of priorities and scope, and in fact never finishes when you consider the life of the home.

[jshen]

So you think it’s reasonable to have no idea what it will cost, or when it will be done, when building software? You think it’s possible to run a successful business that way?

[lmm]

> So you think it’s reasonable to have no idea what it will cost, or when it will be done, when building software? You think it’s possible to run a successful business that way?

It absolutely is; look at some of the biggest and most successful software companies in the world. No-one has any idea what facebook will cost or when it will be done (Zuckerberg has said that he was off by at least 5 orders of magnitude IIRC). No-one has any idea what google will cost or when it will be done. No-one has any idea what amazon will cost or when it will be done. No-one has any idea what netflix will cost or when it will be done.

[tmlb]

You can have some idea, but it’s not like estimating the time and cost of building a house.

[musiciangames]

I make a point of stopping project managers when they use the analogy of building a house to push back on estimates. What was the contractor doing before the current job? Building a house. What will they do after this job? Build a house.

By contrast, software development is doing stuff that hasn't been done before. You may be lucky, and have done something similar. If it's really been done before, you would ideally be using something off the shelf.

For me, a project manager who uses this analogy has no place running a software project.

[mardifoufs]

Construction companies can do all sorts of projects, and still usually have to meet a deadline. Do you think every bridge or skyscraper is the same, just because they are all bridges and skyscrapers? And do you think mechanical engineers are also not estimating delivery dates just because they usually create new stuff? Because that's not the case.

Also, tons of software dev isn't actually about pushing boundaries or doing something that hasn't been done before. In fact, I'd say most development is about implementing known solutions but in a customized way. Just like every other engineering field.

[musiciangames]

The analogy was house building. Generally a house builder will not be building skyscrapers next month.

And the project managers who use the analogy don’t make the comparison with significant and novel civil engineering projects. They make the comparison with having their kitchen extended.

[jahewson]

That sounds exactly like a contractor. "It will be done for $x in y months". Actually it was done for $x * 1.25 in y*2 months.

[biglost]

A few months ago i worked at a company which estimated 2 months, after 1 year and a half it’s still not done, i quit a couple of weeks ago But the client, a really bigcopany, it’s angry but stillwaiting, lying to tjeir upper managent to get a few bonuses

[jshen]

1.25 cost is reasonable, and is solvable by adding a buffer. Taking 2x the time is ridiculous, and a professional should be able to do better.

[dilyevsky]

Well if you find such contractors beyond very small jobs please do let me know ;) because I’ve personally never seen one

[Foobar8568]

Imagine wanting a two floor house with a closed kitchen and once all the wall built you request your contractor to have a single floor one with the garage underground now and an open kitchen with island. With a loose enough contract that they can ask whatever for free.

That's the reality of software development.

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

[hef19898]

Processes are great tools in the hands of good managers / leaders. Good processes in the hands of bad ones, or bad company culture, does not make them good managers.

Outside of software, you see the same thing over and over again with Lean Management and TPS.

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

[jshen]

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

this works, but it’s not the only. You can use a mix of buffers and scope flexibility to hit dates too.

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

[jshen]

I think we’re on the same page, you have to give yourself room to deal with the complexities. It’s not perfect, but it’s a far cry from those saying there shouldn’t be any estimates or date targets with predictable delivery.

[pif]

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

[jshen]

Sure, but that doesn’t mean it’s impossible to do decent estimation with predictable delivery in a relatively healthy environment.