Reddit mentions of The Art of Agile Development

If you are interested in Scrum, I'd recommend reading Software in 30 days and/or Scrum, the art of doing twice the work in half the time or at the very least, read the Scrum Guide. For agile in a larger sense, there are plenty of good books, like The Art of Agile Development or Agile with GUTS

I liked The Art of Agile Development by James Shore and User Stories Applied by Mike Cohn.

When interviewing, I really like to have a casual chat with my potential bosses and teammates about what they *think* agile means and how they use it.

It's a bit tough if you've never seen it work well (which it often does not), and don't have a great basis of comparison, but I'd suggest maybe continuing to read up on the topic and further developing your own opinions of what you think makes sense.

I've been really enjoying Robert "Uncle Bob" Martin's newest book "Clean Agile". And recommend James Shore's book The Art of Agile Development which is perhaps more practical but more dense.

But my personal take on some of the individual points in your post:

> We do "Scrum" with story points (yes we actually call it Scrum)

I like story points :)

> We don't measure velocity

I think this is a big mistake. IMO, one of the core principals of Agile is gathering data and using it to make decisions. If you're already using story points and sprints, velocity would be pretty trivial to measure.

> There are no business analysts

Well I assume there are some stakeholders and businessy people? There should be an open dialog between the developers and these folks as requirements inevitably evolve and change and the project evolves.

> There are no scrum masters

That just puts the burden of responsibility on the rest of you. It's not necessarily a bad thing.

> We have 5 different "feature teams" and each one does "agile" completely different

In my opinion, that in itself is not bad. Agile is about small teams doing small things well. To me, its a red flag when a lot process is enforced at a company-wide level. Teams should be able to exercise some degree of autonomy with respect to finding out how to get their work done. But they have the responsibility to provide frequent and accurate estimates and data on their progress up the chain.

> Some teams do Kanban for some reason?

If it makes sense to them and helps them be productive, than I think thats cool.

> Some teams document properly, others don't document a single thing

Unfortunately thats pretty common. Be part of the solution, not the problem, and try to be an advocate for good documentation, but don't expect to find an employer where this is how you think it should be.

> Daily standups that go an hour, sprint planning, and sprint review meetings

Long standups are a trap that's easy to fall into. Assuming you don't actually "stand up" for them? Maybe try suggesting that as a small change.

Planning & review meetings don't sound like a bad idea to me...

> With all the meetings and points and discussion it feels like every single thing I do is being tracked and I have no breathing room (other than just over estimating points on purpose)

Points on a story really don't have any base value except relative to other stories. So if you over-estimate one, it implies that you are under-estimating others. That is a little concerning. But then again, if you aren't measuring velocity etc... its sorta like Who's Line is it Anyway: "everything's made up and the points don't matter"

> When I bring up the Agile Manifesto people literally laugh at me

If you're actively trying to figure out how to make the process, and not being a dick about it, and people aren't taking you seriously, it might be time to look for a new job. But also, you can't expect to make significant changes to this kind of culture overnight. If you're not ready to give up, maybe approach it from a more pragmatic place, and less philosophical. Suggest tiny experiments where you change something small about the process for a sprint or two. If people laugh at you for actively working to make your team more productive than wtf.

> On top of all this shit are hard dates for when features will be released (!)

Yes, hard delivery dates set by business are a common reality. But you have other things which necessarily must be flexible. Projects can be only 3 out of 4 of the following: cheap, fast, good, and done. If you can't budge on the timeline, it being cheap, fast or good, then it just won't get done. You won't hit the date. But you can decide to give up on some of those properties to get a project done within just about any timeline. Business folks might not like to hear it, but they should appreciate you telling them the reality. "I can hit that deadline sure, but the codes going to be bad, and non-performant."

The environment is the same as it was today as it was yesterday. The pace of change has changed and the amount of information has increased, but the fact things change has remained constant. It is ancient wisdom that "the best laid plans of mice and men often go awry".

The best work I've seen is The Art of Agile Development. This is a book about software project planning, but the advice it offers for planning software projects also applies to life.

In the software development world, there are many different kinds of project planning, two predominant examples being BDUF (Big Design Up Front) and Agile.

The problem with BDUF is that as you learn more information from actually writing the software or customers change their minds through the course of the project, the big plan becomes irrelevant and pretty much discarded. The key failure is that you are making a commitment to a plan when you have the least information.

Agile takes a different approach, what James Shore calls "planning horizons". The idea is the further out in the future you go, the more uncertain things become and the more things become subject to change, and so at each planning horizon the type of planning must be different.

So you plan at different horizons. What are you going to do today? What are you going to do this week? What are you going to do this month? What are you going to do this year? 5 years? 10 years? The further out in the future you go, the more hypothetical it should be. The longer the planning horizon, the more it should be treated as a guide, not a rule.

"Defer decisions until the last responsible moment". Don't lock yourself into big decisions when you have the least information (for example, buying a house). Gather as much information as you can about present circumstances and future circumstances in all areas of your life. Do constant research, make constant adjustments. Always be open to change.