Live data from Hacker News

The Agile Fluency Model

martinfowler.com

21–30 of 112 posts

Re: The Agile Fluency Model

#21
I love this.

"Is [Huge pile of recently promoted buzzwords] not the silver bullet you expected? We've got the answer: [A new pile of buzzwords]!"

"Here are some charts and graphs and vague paragraphs to confuse you and intimidate you into hiring us as expert consultants!"

It's sort of like the Nigerian email scam, in that they don't even try to hide the big piles of B.S. Anyone who makes it through this without rolling their eyes out of their sockets self-selects as likely to fall for the whole thing.

Re: The Agile Fluency Model

#22

> Delivering teams deliver on the market cadence. "delivering teams deliver" -- got that. "... on the market cadence" -- err... market. cadence?

As "market cadence" doesn't mean anything but sort of sounds like it does, you can just define your delivery schedule as being on the market cadence and you are now a delivering team.

When it all goes to shit, the person brought in to clear up the mess can just tut and state that the problem was that the team wasn't delivering on the market cadence after all.

Very handy term if you want to sound good but don't actually want to change anything.

Re: The Agile Fluency Model

#23

> Delivering teams deliver on the market cadence. "delivering teams deliver" -- got that. "... on the market cadence" -- err... market. cadence?

Yeah, it's written in Consultenglish, not the language you speak.

But that sentence just means "an effective team delivers in time for a product to be useful."

... now that is 5000 euros for my consulting service.

Re: The Agile Fluency Model

#24
post #5

The consultants have taken over "Agile" and turned it into a process-heavy set of practices. Over the course of a 2 week sprint I spend more than 8 scheduled hours in various meetings (grooming, planning, scrums,etc.) http://programming-motherfucker.com/

Wasn't the Agile Manifesto written by a group of consultants in the first place?

I mean they say "individuals and interactions over processes and tools".

Re: The Agile Fluency Model

#25
post #20

Your software should be agile, not your process. Your process should be "disturb as little as possible". Either you code or you get out of the way and take responsibility for the people that code by slowing them down just enough to trust them.

I agree with this 100%.

In order to benefit from agile, your codebase and pipelines absolutely NEED to be built in such a way that they can easily accept and ship lots of small changes, and ideally should maximise the efficiency of your code. You should spend most of your time writing business logic, rather than code to facilitate the code that contains your business logic.

Re: The Agile Fluency Model

#26

When management says sprint, you say, “How fast?” I find the language plain disempowering to developers.

In agile are you permanently in a sprint? When one sprint ends you start a new one, right? That's insane - you can't sprint all your life.

It's not "sprint" compared with "walk", as in "go flat out". It's "sprint" compared with "marathon", as in "short burst and we're done".

Using the word 'sprint' as an excuse for permanent crunch time is doing it wrong.

Re: The Agile Fluency Model

#27

When management says sprint, you say, “How fast?” I find the language plain disempowering to developers.

In agile are you permanently in a sprint? When one sprint ends you start a new one, right? That's insane - you can't sprint all your life.

Which is precisely why there is a break between sprints, for planning and downtime...

Re: The Agile Fluency Model

#30
post #5

The consultants have taken over "Agile" and turned it into a process-heavy set of practices. Over the course of a 2 week sprint I spend more than 8 scheduled hours in various meetings (grooming, planning, scrums,etc.) http://programming-motherfucker.com/

The consultants have taken over "Agile" No, what's happened is that BigCorp has decided to adopt Agile and won't adopt anything without a lot of instruction books and role descriptions. The consultants, at least the ones who know what they're doing, have been trying to fight this all along. It's the industry itself that continues to over-engineer everything it touches, from Javascript frameworks to development proces…

It isn't just a "BigCorp" organizational issue. You touched on it, but gently: developers share some blame here. There's a real anti-engineering bias in this industry. I mean engineering as it's practiced in other contexts. There is a process of design and analysis that is done before build and implementation starts that in this industry is considered wasteful or work to be done by lesser mortals who aren't smart enough to code.

That's a big reason why there's all this over-engineering of everything.

Post reply on HN